Don't fallback to legacy in DigestSignInit/DigestVerifyInit too easily
Don't fallback to legacy in DigestSignInit/DigestVerifyInit too easily

The only reason we should fallback to legacy codepaths in DigestSignInit/
DigestVerifyInit, is if we have an engine, or we have a legacy algorithm
that does not (yet) have a provider based equivalent (e.g. SM2, HMAC, etc).
Currently we were falling back even if we have a suitable key manager but
the export of the key fails. This might be for legitimate reasons (e.g.
we only have the FIPS provider, but we're trying to export a brainpool key).
In those circumstances we don't want to fallback to the legacy code.

Therefore we tighten then checks for falling back to legacy. Eventually this
particular fallback can be removed entirely (once all legacy algorithms have
provider based key managers).

Reviewed-by: Nicola Tuveri <5a38b4ac03c90be61ead22c1d11b6e9f49425984@gmail.com>
Reviewed-by: Paul Dale <bc4a6b4cd7a8395c734c8eb5aef04a9c30188c85@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12550)

openssl/openssl,openssl/openssl,openssl/openssl,openssl/openssl,openssl/openssl,openssl/openssl