fix: I use OpenSSL 4.1 ASN.1 string APIs

[w3lld1]

Summary

• I use the OpenSSL 4.1 ASN1_STRING_length_ex() and ASN1_STRING_set_data() APIs when they are available.
• I keep the existing ASN.1 APIs for earlier OpenSSL releases.
• I reject an ASN.1 length that cannot fit in the existing integer key-decoding path.

Validation

• I built the provider with KEM encoders enabled and -Werror=deprecated-declarations against OpenSSL 3.5.6.
• I built the provider with the same options against OpenSSL 4.1.0-dev from the current OpenSSL master branch.
• I ran all 9 CTest tests successfully against both OpenSSL versions.
• I reran the focused oqs_endecode test successfully on the exact commit against both versions.
• I ran the changed-line clang-format check and git diff --check.

Fixes #804

[RodriM11]

Hi @w3lld1 ! Thank you for your contribution. oqs-provider has the peculiarity that (up until this point) one could compile in a certain version and execute in other. With this PR, if one were to compile OpenSSL under a 4.1, it could not be used with any OpenSSL version lower than 4.1, as the new symbols do not exist in previous versions. That is why, in this case, I believe the corroboration cannot be compilation time only, it must be compilation and execution.

[RodriM11]

here the check must be compilation and execution time.

[w3lld1]

Addressed in 5d0a76b: builds against OpenSSL 4.1 now check the runtime OpenSSL_version_num() before calling the 4.1 ASN.1 APIs and fall back to the legacy APIs on older runtime libraries. The legacy calls are isolated behind local deprecation-warning suppression so 4.1 builds remain warning-clean.

I reran the changed-line clang-format check and git diff --check. I could not rerun the C build in this environment because the OpenSSL development package is unavailable; configuration stops before compilation.

[w3lld1]

Thanks — addressed this in 5d0a76b3. The OpenSSL 4.1 API is now guarded at both compile time and runtime, with the legacy length path retained when the provider runs against an older OpenSSL version.

[w3lld1]

Fixed the coding-style failures in b3ec65c by applying the repository's clang-format layout to both encoder dispatch tables. The follow-up commit includes the required DCO sign-off.

Validation:

• clang-format --dry-run --Werror oqsprov/oqs_encode_key2any.c
• git diff HEAD^ --check

[RodriM11]

Must confess I an not a big fan of handling it this way...

[RodriM11]

I understand the idea, but the solution is adding a deprecated flag declaration to hide it if legacy path happens, I do not think is the most optimal way of handling it. Furthermore, it may later hide other deprecation declarations...