Include use of loaded 'libctx' context in KEM and SIG procedures (#557)

[RodriM11]

Inclusion of use of OSSL_LIB_CTX * context in which the oqsprovider is loaded to KeyGen, Encaps, Decaps (KEM) and KeyGen, Sign, Verify (SIG) operations.

This PR is associated with issue #557. I apologize for the delay in the commit.

[baentsch]

Thanks very much for the contribution @RodriM11 ! Just wondering while CI tests this: Would it be feasible to add a test validating this improvement?

[RodriM11]

I wondered that myself when coding it and here is what I came up with. I tested it executing the available test (introducing minor variations to the DRBG procedure, for example) and analyzing the code executed to check that indeed was performing as I expected (but this is clearly not a way to test this). Since the modifications are pertaining to internal structures and not ones directly accessible in a test, it gets harder to do so. The modifications amount to use the OSSL_LIB_CTX * in which the provider is loaded (or, more accurately, a child copy of it) as the context under which the relevant cryptographic operations are performed, instead of the NULL default context. There can be a number of relevant feats one can exploit from this behavior, but perhaps the more visible (useful) is the context from which pseudorandom elements are generated. As such, a possible way to test this modification would be: to create a test that loads a purely deterministic DRBG procedure, and do some 'KAT' like approach in which the test verifies that it always generates the same values (as this would mean that, on every cryptographic procedure with pseudo randomness generation, the modification is working as expected, as I am able to directly set whatever DRBG I wish to). However, this has two inconveniences, IMO:

1. It requires to generate, store and (possibly) updates these values, for every combination and cryptographic element possible.
2. Since this behavior only affects classic elements (the PQ pseudo randomness is managed by liboqs own DRBG), it would be required to separate the classic from the PQ elements and check accordingly. This is no problem for cryptographic keys, but encapsulations, shared secrets and signatures would be much more tedious.
3. It might not capture other uses of the library context that are not directly tied to DRBG procedures.

To have a test of this behavior without having to incur on these problems, I would propose to construct the test in the following way:

1. As a solution to 1., the actual value that is generated is not actually needed, as the test only needs to check that the generation is deterministic (i.e., two executions generate the same result). Therefore the test could be to generate each cryptographic element twice (under a deterministic pseudorandom generation) and check they match.
2. As a solution to 2., the test could also load a deterministic pseudorandom generator to liboqs. This way, it would avoid the problem of having to separate between classic and PQ elements. This approach, however, has a minor caveat IMO: while the test could load a custom DRBG and then, at the end of it, load the default DRBG of OQS (which should be an appropriate behavior for a standard use of liboqs), it could mean that if somebody were to load another custom DRBG before executing the tests, this DRBG would be 'unloaded'. It also has the inconvenience of having to directly access liboqs on the test, which is something that migth be desired to be avoided.