We're removing the engine, so we don't need to test this anymore.

NOTE: This also removes the engine skip check from the test, and this
breaks testing until such time as PR openssl#28461 is merged (which replaces
the remaining engine test with a provider).

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

Spotted by @andrewkdinh, some extra notes about/useages of engines that
are now vestigial.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

The evp_extra_test code makes use of the dasync engine to ensure that we
can do evp operations (signatures and ciphers) with an engine.

The dasync engine is used for this purpose, but it does not exercize any
specific pipeline functionality.

Given that engines are getting removed, the engine tests here I think
can just be removed.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With the impending engine removal, we don't have a need to test engine
functionality in these tests anymore, so remove the test cases that make
use of the dasync engine here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

It seems like it wasn't ever needed before, so with the removal of
engines, just get rid of it.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We have a specific test suite that exercizes the afalg engine, that is
becoming useless with engine removal.

I had considered that we should perhaps convert this into a provider,
but having looked at the engine itself, it only offers implementations
for AES-128, AES-192 and AES-256.  Given that the default provider
offers these algorithms with hardware acceleration via the aesni
instruction set (or comparable instructions on non-x86 arches), it seems
like the only advantage the afalg engine offers is acceleration of these
ciphers on platforms that have off-cpu accelerators and no cpu based
acceleration support.

given that:
a) Most cpus have instruction based acceleration
b) We don't test with any platforms that use external accelerators

It seems like alot of investment to get no real advantage, so just
remove the test, allowing us to delete the engine entirely in another
PR.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With engine removal, we expect that init flag to disappear, so stop
using it here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We're removing the engine, so we don't need to test this anymore.

NOTE: This also removes the engine skip check from the test, and this
breaks testing until such time as PR openssl#28461 is merged (which replaces
the remaining engine test with a provider).

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

Spotted by @andrewkdinh, some extra notes about/useages of engines that
are now vestigial.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

The evp_extra_test code makes use of the dasync engine to ensure that we
can do evp operations (signatures and ciphers) with an engine.

The dasync engine is used for this purpose, but it does not exercize any
specific pipeline functionality.

Given that engines are getting removed, the engine tests here I think
can just be removed.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With the impending engine removal, we don't have a need to test engine
functionality in these tests anymore, so remove the test cases that make
use of the dasync engine here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

It seems like it wasn't ever needed before, so with the removal of
engines, just get rid of it.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We have a specific test suite that exercizes the afalg engine, that is
becoming useless with engine removal.

I had considered that we should perhaps convert this into a provider,
but having looked at the engine itself, it only offers implementations
for AES-128, AES-192 and AES-256.  Given that the default provider
offers these algorithms with hardware acceleration via the aesni
instruction set (or comparable instructions on non-x86 arches), it seems
like the only advantage the afalg engine offers is acceleration of these
ciphers on platforms that have off-cpu accelerators and no cpu based
acceleration support.

given that:
a) Most cpus have instruction based acceleration
b) We don't test with any platforms that use external accelerators

It seems like alot of investment to get no real advantage, so just
remove the test, allowing us to delete the engine entirely in another
PR.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With engine removal, we expect that init flag to disappear, so stop
using it here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We're removing the engine, so we don't need to test this anymore.

NOTE: This also removes the engine skip check from the test, and this
breaks testing until such time as PR openssl#28461 is merged (which replaces
the remaining engine test with a provider).

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

Spotted by @andrewkdinh, some extra notes about/useages of engines that
are now vestigial.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

The evp_extra_test code makes use of the dasync engine to ensure that we
can do evp operations (signatures and ciphers) with an engine.

The dasync engine is used for this purpose, but it does not exercize any
specific pipeline functionality.

Given that engines are getting removed, the engine tests here I think
can just be removed.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With the impending engine removal, we don't have a need to test engine
functionality in these tests anymore, so remove the test cases that make
use of the dasync engine here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

It seems like it wasn't ever needed before, so with the removal of
engines, just get rid of it.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We have a specific test suite that exercizes the afalg engine, that is
becoming useless with engine removal.

I had considered that we should perhaps convert this into a provider,
but having looked at the engine itself, it only offers implementations
for AES-128, AES-192 and AES-256.  Given that the default provider
offers these algorithms with hardware acceleration via the aesni
instruction set (or comparable instructions on non-x86 arches), it seems
like the only advantage the afalg engine offers is acceleration of these
ciphers on platforms that have off-cpu accelerators and no cpu based
acceleration support.

given that:
a) Most cpus have instruction based acceleration
b) We don't test with any platforms that use external accelerators

It seems like alot of investment to get no real advantage, so just
remove the test, allowing us to delete the engine entirely in another
PR.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With engine removal, we expect that init flag to disappear, so stop
using it here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We're removing the engine, so we don't need to test this anymore.

NOTE: This also removes the engine skip check from the test, and this
breaks testing until such time as PR openssl#28461 is merged (which replaces
the remaining engine test with a provider).

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

Spotted by @andrewkdinh, some extra notes about/useages of engines that
are now vestigial.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

The evp_extra_test code makes use of the dasync engine to ensure that we
can do evp operations (signatures and ciphers) with an engine.

The dasync engine is used for this purpose, but it does not exercize any
specific pipeline functionality.

Given that engines are getting removed, the engine tests here I think
can just be removed.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With the impending engine removal, we don't have a need to test engine
functionality in these tests anymore, so remove the test cases that make
use of the dasync engine here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

It seems like it wasn't ever needed before, so with the removal of
engines, just get rid of it.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We have a specific test suite that exercizes the afalg engine, that is
becoming useless with engine removal.

I had considered that we should perhaps convert this into a provider,
but having looked at the engine itself, it only offers implementations
for AES-128, AES-192 and AES-256.  Given that the default provider
offers these algorithms with hardware acceleration via the aesni
instruction set (or comparable instructions on non-x86 arches), it seems
like the only advantage the afalg engine offers is acceleration of these
ciphers on platforms that have off-cpu accelerators and no cpu based
acceleration support.

given that:
a) Most cpus have instruction based acceleration
b) We don't test with any platforms that use external accelerators

It seems like alot of investment to get no real advantage, so just
remove the test, allowing us to delete the engine entirely in another
PR.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

With engine removal, we expect that init flag to disappear, so stop
using it here.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

We're removing the engine, so we don't need to test this anymore.

NOTE: This also removes the engine skip check from the test, and this
breaks testing until such time as PR openssl#28461 is merged (which replaces
the remaining engine test with a provider).

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)

Spotted by @andrewkdinh, some extra notes about/useages of engines that
are now vestigial.

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#28525)