Improve ergonomics around owned::Id and borrowed::Id

[Byron]

Benchmark it and different alternatives like:

• using Cow
• using owned::Ids everywhere

Be sure to put Sha256/32 bytes in there right away to have a more faithful prediction of the future and prevent optimizations that currently are definitely at play.

The outcome is to find the tradeoff between ergonomics and performance and apply the change to the codebase.
Also: Select one name for the type and use it everywhere unchanged, right now some crates use it as Digest.

[Byron]

Insights gained

All the time the trait I was looking for was Borrow. The current implementation that enforces Owned and Borrowed versions of the same thing are me trying to poorly emulate what AsRef<> could do, with the difference that Borrow<> will take ownership if you let it (along with possibly instantiating huge functions/methods.

Thus we should do the following:

• Remove git_object::(borrowed|owned)::Id and HashKind as these lead to people depending on git_object instead of git_hash (like happed with git-commitgraph)
• Find a way to have multi-length borrowed Ids (as slice) and use the fact that the length of a hash digest encodes its type. It's likely these will only grow so we should be safe for a while. Effectively, this is relevant for borrowed::Tree, so we might even keep the code there and greatly simplify git-hash (pushing some of the code into git-object). Conversions from owned Ids to borrowed ones are cheap, the other way around involves a copy. It's also relevant for all zero-copy return values of hashes.
  • The type ideally is properly borrowed, such as in &borrowed::Id, which enables ToOwned traits and Borrow to be used properly.
• Receivers of borrowed hashes that are public facing should use impl Borrow<hash::Id> for convenience, internal receivers should use plain references. Avoid putting generics into receivers with lots of code but instead use 'landing pads'.
  • Review crates to find refactoring opportunities. There is great benefit in having zero-copy object Ids and there is no way to remove them from the equation. However, they should just be slices, see the next point. Maybe make it easy to use owned Ids as borrowed ones.
    • git-commitgraph lookup
    • git-object
    • git-odb::*::locate()
• Unify name to be Id everywhere.
• Add Sha256 support for good measure (it should be representable in the type system, not working for everything), assure that adding it actually works as anticipated. It' not the time yet, see comment at bb24dc4
• Rename git_hash::Oid to git_hash::ObjectId and git_hash::borrowed::Id to git_hash::oid 🎉
• Make ObjectId and oid comparable (Eq, Ord) for convenience, remove 'as_ref()' where it was added because of these missing

Then republish these crates with breaking changes:

• git-features (git-hash in public interface)
• git-hash (rename)
• git-object (less public export)
• git-odb
• git-commitgraph (use git-hash)
• git-protocol
• gitoxide-core

Correction

When looking at how git_hash::Borrowed is actually used it's clear these are for keeping them in fields of structures, which seemed impossible to do with git_hash::Owned() - let's test more.

This usage as field is in exactly one spot: Tree::entries refers to a vector of borrowed name/bin-hash-id . Packs for instance can be created from readers and thus copy the hash's bytes (there is no buffer to reference), or from a byte buffer, but the API ops to always copy the bytes instead of referencing them. It's a potential optimization which probably isn't worth it as these deltas are only used in thin packs. So the verdict remains: all the fuzz about Owned and Borrowed hashes is merely for one use in the deserialized zero copy Tree.