Stabilize Payjoin V2 Implementation for payjoin-cli Beta

[DanGould]

Payjoin v2 BIP 77 spec employs RFC 9180 Hybrid Public Key Encryption (HPKE) for both Oblivious HTTP and end-to-end authenticated encryption between senders and receivers.

The BIP specified cryptographic dependencies are secp256k1-based DHKEM for HPKE, [RFC 8439 ChaCha20Poly1305 AEAD](https://www.rfc-editor.org/rfc/rfc8439], and HKDF-SHA256 since their cryptographic dependencies are already utilized by bitcoin software.

The existing hpke crate used for OHTTP uses other cryptographic primitives. The payjoin v2 implementation in this crate uses a secp256k1 hpke implementation defined here rather than the hpke crate for sender-receiver AEAD.

That's because the ohttp crate does not yet support secp256k1 DHKEM. Since payjoin is designed for bitcoin settings, using secp256k1 and especially the common libsecp256k1 crate would allow us to reduce dependency burden downstream.

Stabilizing the protocol implementation will require 3 steps

1. Enable Secp256k1 DHKEM and ChaCha20Poly1305 AEAD in the hpke crate for ohttp

This is being tracked by #126

The underlying hpke change is rozbb/rust-hpke#52

2. Replace our HPKE implementation with the more standard hpke crate's.

Deploying a standard HPKE protocol will allow the crate and implementation to be interoperable with other implementations which may crop up even if the underlying implementations of cryptographic primitives change.

Another option would be to write many tests showing that our protocol conforms with HPKE standards, but it would make more sense to combine our efforts with the better-reviewed-for-that-specific-purpose hpke crate.

#125 Can take place in parallel to #126.

3. Replace RustCrypto dependencies with those shared in the rust-bitcoin ecosystem, like the secp256k1 libsecp256k1 bindings crate.

Virtually all downstream bitcoin software uses libsecp256k1 library. It makes sense for us to try to either have that supported in the hpke crate or create a fork that relies on libsecp256k1. It may also make sense to use the same chacha20poly1305 rust implementation from rust-bitcoin or allow for a crypto provider since some operating systems now support it. Sha256 could come from bitcoin-hashes. Using common dependencies allows downstream software to reduce the size of their dependency tree for both for faster and smaller binary delivery and compile times as well as a reduced attack surface.

4. Decide on a URI encoding for payjoin params pj subdirectory and ohttp

Base64Uri encoding, which we use as of now for these parameters, uses both upper and lowercase letters. Because of this it doubles the density of QR codes representing them. We could use another encoding like UR, since both are already properly serialized secp256k1 pubkey and OhttpKey configuration data blobs. Lightning invoices use bech32, but we don't have multiple fields to serialize in that format. In any case we need to finalize the encoding. It would also be wise to confirm that the way we're issuing subdirectories at the payjoin-directory server will not result in collisions.

@jbesraa