Re-try loading ENGINE keys with a non-NULL UI_METHOD

[vcsjones]

When loading a key from an OpenSSL engine, the ENGINE_load_private_key or ENGINE_load_public_key function is used, depending on the key. These functions accept a parameter called ui_method that an ENGINE can use if loading the key requires user interaction, such as a passphrase.

Currently, we pass NULL in to the ui_method parameter since we expect this functionality to be used from non-interactive scenarios.

OpenSSL also passes this parameter as-is to the engine. It does not do a NULL check.

Some engines, like tpm2tss, do not permit a NULL UI_METHOD and immediately error.

This change attempts to accommodate those engines by re-trying the key load with a UI_METHOD that does nothing. This is functionally equivalent to UI_null() from OpenSSL.

We do not try a non-NULL UI first to maintain as much compatibility as possible. .NET has always passed NULL to engines thus far, and an engine can do with that as they want - like falling back to their own UI, using OpenSSL's default, etc. If we unconditionally pass our UI_METHOD, that might break another engine that was happily doing the right thing with NULL.

Contributes to #109243

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[vcsjones]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/11820846271

[vcsjones]

/backport to release/9.0-staging

[github-actions]

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11820930729