Improve Message constructors

[tcharding]

Observe:

• The word "hash" can be a verb or a noun, its usage in function names is therefore at times ambiguous.
• The function name from_slice gives no indication as to what the slice input is.

Improve Message constructors by doing:

• Add a constructor Message::from_digest that takes a 32 byte array as input.
• Rename Message::from_slice to Message::from_digest_slice (deprecate from_slice and add from_digest_slice)
• Improve the docs while we are at it.

Note

The original PR conflate 2 separate issues, the Message constructor naming clarity issue and the upgrade difficulty issue, PR is now only a solution to the first. The second will be done as a separate PR.

[tcharding]

With this PR we can use Message::from_hash(sighash.to_byte_array()) in rust-bitcoin instead of relying on the ThirtyTwoByteHash trait, then we can have two different versions of hashes at the same time and BOOM! no more dependency hole.

[apoelstra]

A few thoughts:

• ACK introducing the from_hash constructor.
• ACK renaming from_slice... though we should just rename it from_hash_slice and provide a giant warning. No need to call it insecure. It's not just used for testing; there are lots of contexts where you obtain a hash in the form of a slice rather than array.
• I would still like to keep (and use) the ThirtyTwoByteHash trait. But you suggested in another thread that we could try moving that trait to bitcoin_hashes.
• Finally, I think we should semver-trick the trait so that it's the same trait in every version of bitcoin_hashes. That might fix our upgrade grief? Similarly we could make the bitcoin_hashes dep in this crate be a range of major versions.

[tcharding]

PR now does the first two points you suggest, will play with second two in a separate PR.

[apoelstra]

Looks good! I have a mild preference to use hash rather than digest but maybe this is the right approach, since hash is a pretty overloaded word already..

[apoelstra]

ACK cd40ae7

[tcharding]

Looks good! I have a mild preference to use hash rather than digest but maybe this is the right approach, since hash is a pretty overloaded word already..

I got worried over night thinking about this because it introduces non-uniformity "why hash here and digest there?" since we barely use the word "digest" anywhere. I've been down this path before in years gone past and its a bit like pushing against the whole world. The "hash is a verb and noun" thing is a real problem though.

[Kixunil]

Regarding ThirtyTwoByteHash, if we truly want to avoid the hole we should just put it into a completely separate crate bitcoin_32b_hash which would be nearly instantly stable and then depend on that from both hashes and secp256k1 instead. It's the most principled approach, although I can see some people won't like more dependency lines.

[apoelstra]

Aside from the "more dependency lines" issue (and IMO I would rather deal with the hole than have a more complicated dep tree), I think we considered this and had some issue with the orphan rules and blanket impls. But I don't remember specifically where.

[Kixunil]

We could have the dep tree complicated only until stabilization and then incur one last break. I'm willing to look at the orphan problem if this is acceptable. At the very least From<T> should be implementable for our type.