Determine which SSL handle should be used in callbacks on accepted connections

[t8m]

Copying the relevant comments from the discussion in this PR: openssl/openssl#25874

@mattcaswell: Question: It doesn't affect this PR but I wonder what happens in the feature/quic-server branch with callbacks. Have we always been guaranteed to have called SSL_accept_connection before the first TLS callback might be called? If not there might not be a user SSL to pass to the callback yet!!

@t8m: Hmm... this might be unfortunately the case for all the callbacks that can be triggered by the initial handshake frames from the client - perhaps we should delay processing these until SSL_accept_connection() is called?

@vdukhovni: Well, the whole point about "The user SSL" is that it is some object to which the user might have attached some "extdata", i.e. something created well before the handshake. In the case of server callbacks, that'd be the acceptor SSL handle that was listening for incoming connections, not the accepted SSL that materialises after.

Which handle will be used in callbacks here?

If perhaps some callbacks really need the accepted connection, while others (typically at least those related to session management) need the preëxisting acceptor connection, we have a problem, and potentially need to either copy extdata when creating the accepted SSL handle, or to give the user an early opportunity to decide how the accepted SSL should be "decorated" (new callback that gets to see both handles), before any other callbacks are invoked.

[mattcaswell]

Possibly we should proactively create the "user" SSL object when we create the channel, even if SSL_accept_connection has not yet been called. There could also be a new callback on channel creation passing the user SSL to give the application an opportunity to decorate it as they see fit. SSL_accept_connection would just pass back the pre-created user SSL.

[vavroch2010]

After the draft design is created, it must be reviewed by @mattcaswell and/or @vdukhovni