quic: update ngtcp2, openssl APIs, and use ngtcp2-crypto

[jasnell]

Adopts the BoringSSL APIs based on openssl/openssl#8797. We may need to update the license accordingly. These will need to be tracked over time.

Update the implementation to use the new ngtcp2_crypto helper.

Note: because of the need to use the BoringSSL APIs, QUIC will not be available when using shared_openssl. Still need to make sure that's disabled in the build.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[jasnell]

Ok, I've narrowed it down. ngtcp2 is buffering the handshake data and exiting because the handshake keys on the client side are not installed at the right time. ngtcp2 made a change that assumes that both the rx and tx handshake keys are available at the same time, which is based on the assumption that the boringssl quic APIs are being used. The timing of the KeyCB approach we currently have is different so we're running into an issue. Very happy that I finally narrowed that down but now need to find a fix for it...

[jasnell]

Ah, well, this is going to be a fun one... Digging into it... tatsuhiro-san's initial modification to openssl to support quic included adding the key callback we use the get the keying material. That version of the quic modifications would invoke the key callback once per generated secret by patching into openssl's existing tls13_change_cipher_state function. The BoringSSL api approach is to actually branch to an entirely different quic_change_cipher_state function that generates the client and server secrets for each cipher level at the same time. This is a cleaner and more correct approach but to get it working for us since we don't have the boringssl APIs yet, we're going to have to patch on top of the original patch. 🎉 💯 The moral of the story is that as soon as we can move to the boringssl APIs, the better. I'll start working up the additional openssl patch tomorrow

[jasnell]

Ok, progress! With the two additional commits here we get a lot further along in the TLS handshake but we're still not all the way yet. Still digging...

[jasnell]

Testing is confirming that we are now completing the client side of the TLS handshake! The server side, however, is still not completing. I'll track that down tomorrow.

[jasnell]

PROGRESS! Ok, with a couple of exceptions, things should be working. There's still work to do in this PR to get things cleaned up. The one thing that's not working is accessing the client certificate on the server side. That's what I'll be chasing down tomorrow. But, progress has been made.

[jasnell]

WOO! Ok, this should be ready to go. There are still a few pieces that need to be revisited but we need some fixes in ngtcp2 to resolve those (see ngtcp2/ngtcp2#156)

[jasnell]

There's one commit in here that needs to be upstreamed... ngtcp2/ngtcp2#157