limit testing to oqsprovider

[baentsch]

Fixes #609 .

Question to the community, particularly @mattcaswell @t8m @SWilson4 : Should we limit all testing to oqsprovider or still allow interaction with other implementations for the same algorithms in different providers (propq==NULL) as is still possible for some tests as per this PR? See also #610 .

Advantage: Other code also gets tested.
Disadvantage: oqsprovider code may not get tested.

The latter leads me to prefer extending this PR to limit all testing completely to provider=oqsprovider and not just of experimental features that are OQS-specific as with this the PR as done initially.

[t8m]

IMO OQS provider testing should test primarily the OQS provided implementations. Of course once some PQ algorithm implementations are implemented in OpenSSL code itself, it might make sense to have some kind of interoperability tests between the respective OQS provider and OpenSSL provider implementations as part of OQS provider tests. I would wait with these tests for these OpenSSL implementations to be at least merged to the OpenSSL master branch though.

[t8m]

Another option would be to execute the tests that work with both OpenSSL PQ implementation and OQS provider implementation twice - once with the propquery set and once without it.

[vdukhovni]

Another option would be to execute the tests that work with both OpenSSL PQ implementation and OQS provider implementation twice - once with the propquery set and once without it.

But only tests that really are expected to be provider independent. In particular, tests that depend on provider-specific properties need to load the algorithm from just the provider in question.

[SWilson4]

Fixes #609 .

Question to the community, particularly @mattcaswell @t8m @SWilson4 : Should we limit all testing to oqsprovider or still allow interaction with other implementations for the same algorithms in different providers (propq==NULL) as is still possible for some tests as per this PR? See also #610 .

Advantage: Other code also gets tested. Disadvantage: oqsprovider code may not get tested.

The latter leads me to prefer extending this PR to limit all testing completely to provider=oqsprovider and not just of experimental features that are OQS-specific as with this the PR as done initially.

I agree, we should ensure as first priority that the full functionality of oqs-provider is tested.

[baentsch]

I agree, we should ensure as first priority that the full functionality of oqs-provider is tested.

This is what this PR (now) does. Please check and approve.