src/fsverity.rs defines Sha256HashValue as an implementation of
FsVerityHashValue but we also use it for situations where we handle
SHA-256 digests that aren't fs-verity hash values.  This happens a lot
in the OCI code (to refer to images and layers) and correspondingly in
the splitstream code (which stores those things).

Introduce a util::Sha256Digest type, returned by util::parse_sha256()
and use it consistently for all of the cases that have nothing to do
with fs-verity.

parse_sha256() is still used in some places in the code for values that
are intended as fs-verity digests.  We'll start fixing that up in the
following commits when we add some helpers directly on the types
themselves.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

Split FsVerityHashValue and its two implementations out to a separate
file.  Right now it's not a lot of code, but it's going to get
substantially larger in the next commit.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

Right now we define

  pub type Sha256HashValue = [u8; 32];
  pub type Sha512HashValue = [u8; 64];

which is simple enough but also painful: we can implement our own traits
for these types (and indeed, we do it for FsVerityHashValue) but we
can't implement things like fmt::Debug because there's a default impl
(which rather unhelpfully prints the hashes out as an array of bytes).

Turn these into proper types using a trivial struct wrapper:

  pub struct Sha256HashValue([u8; 32]);
  pub struct Sha512HashValue([u8; 64]);

which gives us a lot more control.  We can start by implementing
meaningful fmt::Debug traits.

Doing this means that we implicitly lose our implementation of
AsRef<[u8]> and AsMut<[u8]> which we've been mostly using in order to do
various ad-hoc encoding to/from various forms of hex values all over the
codebase.  Move all of those ad-hoc forms of encoding into proper
methods on the trait itself by adding functions like ::to_hex() and
::from_hex() which we can use instead.  We also drop our last instances
of using parse_sha256() for fs-verity digests.

There are a couple of other places where we need the actual bytes,
though: when reading/writing hash values to splitstreams and when
reading/writing the metacopy xattr in erofs images.  Deal with those by
deriving the usual zerocopy FromBytes/IntoBytes traits for our new hash
types and moving the code in the splitstream and erofs modules to
directly include the data inside of the relevant structure types, mark
those types as FromBytes/IntoBytes, and use the zerocopy APIs directly.
In the case of the metacopy attr in the erofs code this provides an
opportunity for a substantial cleanup in an otherwise scary part of the
code.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

This tests out all of the various conversions we can do.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

Various bits of code here predate my having learned what Self.  We're
about to throw a bunch of generic type arguments absolutely everywhere,
so increase our use of Self first to help make that less painful.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

Let's pass a string instead of a Sha256HashValue to write_entry().  This
will save us a substantial amount of grief with generics in the next
commit.

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

Convert all of the many places that we've been using Sha256HashValue for
fs-verity hashes to be generic over FsVerityHashValue instead.  Work the
changes out across the codebase.

Due to some missing features in Rust, this change (while fairly
mechnical) is also pretty large.  See for example:
 - it's not possible to omit type parameters from the declaration of a
   function when they are irrelevant to the body of the function
 - rust-lang/rfcs#424

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>

This syntax is a bit less verbose than the fully-spelled-out generic
form.  I'm surprised by how few sites this was possible for...

Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>