Undeprecating EVP_PKEY_set1_RSA and friends API

[beldmit]

This is a follow-up/spin-off to #23609

Many applications use RSA/EC_KEY/DH objects for keys and create them, for example, from specific formats. When these objects rely on custom (deprecated) METHOD structs, they can't be used by providers. But for most case after an assigning an RSA object to a EVP_PKEY an export-import dance happens and then providers will be used for crypto operations. The alternate approach is to build EVP_PKEY from params or writing custom per-app decoders/encoders.

The EVP_PKEY_set1_* significantly simplifies application migration and, when FIPS indicators are implemented, we can distinguish the case when the key is not FIPS-compliant and, when FIPS implementations are used, we can either fail the operation or raise a failure indicator so we at least partially remove the reasons to deprecate these functions.

[slontis]

I dont think this is a good idea.

[beldmit]

I don't know so I'd like to see the arguments pro et contra

[t8m]

This basically means to undeprecate the low level RSA/EC_KEY/DH objects and all the related functions for setting them up. That would be extremely bad idea as we want applications to move out of their use. We want even drop these legacy low level handling at some point.

Please note that FIPS support was not the only reason for these deprecations. Yes, there is the internal export/import handling so EVP_PKEY keys created with these set1 functions can do operations in the FIPS provider, but it does not mean that it is a good idea to revive these deprecated APIs. There will never be such kind of low-level APIs for post quantum keys and thus these functions are really legacy and their use should diminish over time.