Implement computing SHA256 in const context

[Kixunil]

Computing hashes in const fn is useful for esily creating tags for sha256t. This adds const fn implementation for sha256::Hash and the algorithm for computing midstate of tagged hash in const context.

Part of #1427

I'd like to make sha256t evocative of the output after this which would also do the thing we want to do with #1427 (awkward language to bypass GH automatically closing it...) I'm thinking of this:

sha256t_newtype_hash! {
// optional attrs
/*pub*/ struct TagName = "tag_str"; // weird syntax but I guess OK-ish?

// optional attrs
/*pub*/ struct HashName(_); // allowed to elide the type because it's implied; maybe also allow writing it?
}

What do you think? I was also thinking about this alternative:

sha256t_newtype_hash! {
// optional attrs
/*pub*/ struct TagName;

const TAG: Tag = from_str("tag_str"); // allows for having from_raw([...]) or even from_hex([...])

// optional attrs
/*pub*/ struct HashName(_); // allowed to elide the type because it's implied; maybe also allow writing it?
}

Which looks more natural but maybe too much boilerplate? Which one do you like? Any better ideas? Heads up sanket1729

Also FYI tcharding this is the kind of post-1.48 change I was thinking about. :)

[apoelstra]

The integration test "failures" look like a series of annoying warnings that we've promoted to errors.

concept ACK this (and will give a real ACK soon). Are the warnings about efficiency purely because we use while loops instead of iterators? Because I expect the compiler can handle a i = 10; while(i--) { .. } loop just as well as any iterator-based code.

As for the question about macro syntax, I prefer the from_str(...) variant since it's more extensible, as you say.

[Kixunil]

I don't see any loop errors, just operator precedence. I think I'll #[allow] it.

We could also have struct Tag = hash_str("tag_str"); to decrease boilerplate. (hash_str seems better than from_str).

[Kixunil]

Oh, now I understood your question about loops. 🤦‍♂️ Yes, and you are probably right, I tried some stuff in godbolt and looks good. However there's still a reason to consider it: we may move to use native CPU instructions. There are discussions about conditionally running different code in const and non-const (in fact an unstable intrinsic already exists) but those seem far in the future.

Although honestly I'm kinda tempted to do it and thus enable a bunch of things in bitcoin to be const.

[apoelstra]

ACK 42d3ae0

[tcharding]

ACK 42d3ae0