Don't free the EVP_PKEY on error in set0_tmp_dh_pkey() functions

[mattcaswell]

We should not be freeing the caller's key in the event of error.

Fixes #17196

[vdukhovni]

I should perhaps ask whether the security level check should avoid a time of check vs. time of use issue?

Currently the DH key is checked against the security level that's effective at the time at which the key is configured, but the security level can change after that, perhaps for a specific SSL connection, ...

I don't know whether an already configured key is rechecked at time of use? The right thing to do may be to ignore out of spec keys (as if not configured), or (more intrusive) fail the attempted handshake? But a check at time of configuration may not quite provide the expected semantics?

[paulidale]

@vdukhovni, that sounds like a different issue to this.

[vdukhovni]

@vdukhovni, that sounds like a different issue to this.

Yes, I stand by the approval on the pull request. But it just occurred to me while I was thinking about the semantics, and thought I'd mention it before I forget. If you think it may warrant further discussion, we could open a new ticket, but if it seems unimportant, we could drop it...

[paulidale]

A new ticket seems reasonable. It's not something I'm aware has been discussed previously and it's not clear what semantics make the most sense.

[openssl-machine]

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

[mattcaswell]

Pushed. Thanks.