Refactor of fuel-crypto for clarity around safety

[mitchmindtree]

This started with the aim of carrying over FuelLabs/fuel-crypto#36 which aimed to address FuelLabs/fuel-crypto#35, though after noticing a few other instances of the same issue decided to take a closer look throughout the crate.

This PR removes many of the unsafe constructors exposed in the fuel-crypto API, some due to the implementations not actually being unsafe, and some due to a revised implementation that safely encapsulates the unsafe behaviour.

The Message and Signature from_bytes and from_bytes_ref constructors have been documented to clarify expectations that they expect signature or cryptographically hashed data respectively.

The PublicKey and SecretKey from_bytes_unchecked constructors have been made private in order to ensure holding an instance of one of these types guarantees their inner byte arrays at least satisfies the curve.

The original, custom curve-checking functions have been removed in favour of using the secp256k1 library constructors directly which share the same implementation but with an added range check that is likely to get optimised out due to the use of const-sized arrays anyway.

Adds some missing #[repr(transparent)] decorators to fuel-types.

The FuelMnemonic type provided unnecessary indirection between the user and the free function, and has been removed in favour of exposing the function directly from the crate root.

[mitchmindtree]

TODO: The original is_slice_in_curve_unchecked function would also leave the first byte zeroed before invoking the secp256k1 pubkey parser like this, so I've carried over the behaviour in this function. However, it looks like we should possibly be setting the first byte to SECP_UNCOMPRESSED_FLAG? Should investigate or open an issue before landing.

[freesig]

What happens if this is not a valid signature? I know we use this function in fuel core with bytes from the network so maybe we need to add from_bytes_checked -> Option<Self>

[mitchmindtree]

Afaik there's no way to know if the signature is valid until we actually try to validate the transaction, as we don't know what data has been signed at this point.

It should be fine to use this with bytes read from the network as if the signature isn't valid, the transaction validation will fail because the signature won't be valid for some spend or whatever.

[freesig]

Does this actually uphold the lifetime. If the bytes array is moved after this call and &Self is still being used, do we get a compile error? If not this should still be an unsafe function right?

[mitchmindtree]

Does this actually uphold the lifetime.

Yes, in this case the lifetime of the reference in &Self is bound by the only input lifetime, i.e. the lifetime of bytes: &[u8; Self::LEN]. In this case, Rust elides the lifetime because there is only one possible valid lifetime for the output. Here is what the un-ellided signature would look like:

    pub fn from_bytes_ref<'a>(bytes: &'a [u8; Self::LEN]) -> &'a Self {

[freesig]

Should these be results instead of panics?

[mitchmindtree]

If these fail, I believe it's a bug in our implementation logic, i.e. these should always be correct because bx and cx are exactly Bytes*::LEN greater than b or c respectively.

[Voxelot]

This would also be a good opportunity to upgrade from secp256k1:0.24 to secp256k1:0.26

[mitchmindtree]

Feel free to merge this when ready (keeping in mind there is a little breakage of the pub API).