Introduce a 32-bytes key type without additional hashing to Kademlia DHT

Moved from the rust implementation issue as requested by @mxinden.

Description

We need to use DHT to find closest peers with exact PeerId to the exact key value in our network. Currently, both rust and reference golang implementations seem to hash both PeerId and all the provided keys regardless of the initial format (using SHA256 hasher) to get 32-bytes hash before computing the XOR-distance. But what if we pre-hash our data and provide the 32-bytes as PeerId and 32-bytes key value as they are? Is it possible to have an additional way to create keys to calculate the XOR-distance without the additional hashing?

In our use case we attach semantics to both PeerId and look-up keys (related to local data ranges), but the second hashing destroys that. Currently, I use unsafe memory operations to bypass such a limitation but there should be a better way. Also, I don't see any limitations to this change in the original Kademlia paper.

Please, advise - is it possible to add exact keys(without the second hashing) to kademlia operations?

Motivation

This change will enable use-cases that depend on unmodified peer IDs or look-up keys.

Current Implementation

The current implementation hashes the provided keys even if the underlying data is 32-bytes array.

Are you planning to do it yourself in a pull request?

If the proposed enhancement looks reasonable we could implement it.

Start by reviewing the linked rust implementation issue and the current Kademlia specification and implementations mentioned in this report. Determine whether 32-byte PeerIds and lookup keys can avoid additional hashing, including API and compatibility implications. Done means reaching a clear feasibility decision and documenting the required specification or implementation changes.