Migrate x25519 to use rust-openssl

[alex]

No description provided.

[alex]

Ok, BoringSSL test failures are quite a yak shave:

• rust-openssl's usual binding approach is hand-written, this includes the values of constants (e.g. EVP_PKEY_X25519)
• The values it has are from OpenSSL. BoringSSL doesn't use the same ones.
• This causes EVP_PKEY_CTX_new_id to fail since its looking for something by the wrong ID.
• sfackler/rust-openssl@e610c0f describes how linking BoringSSL into rust-openssl requires special handling.
• Right now we simply treat BoringSSL the same as OpenSSL, so more thought is required here.

[alex]

Self-notes:

• Hang is in memleak test_x25519_pubkey_from_private_key
• Stack at the point of the hang: x25519 generate -> calls into OpenSSL -> calls into something else in OpenSSL (probably to allocate) -> calls into an ffi callback (probably our memleak malloc) -> tries to acquire the GIL and hangs
• This obviously all works on CPython
• The proximate change here is that with this PR we're not releasing the GIL on generating a key (or anything else for that matter)
  • Unclear if we should release it for key gen; generating 32 random bytes should be very fast
  • Even if we did release the GIL here, it'd just kick the can down the road
• Unclear if having a cffi callback invoked with the GIL held is expected to work or not (though it clearly does on CPython)