feat: add a rendezvous hash implementation

[tstirrat15]

Description

Written with LLM assistance.

In SpiceDB we use consistent hashing to route the the same dispatch key to the same SpiceDB node, which theoretically increases cache hit rate and reduces hotspotting. Consistent hashing assumes a relatively stable set of nodes, because the hashring is precomputed and recomputing the hashring is expensive. An upside of precomputation is that routing an individual request is cheap.

This causes problems when nodes enter or leave the cluster, however. This whole saga started when we opened #5, and since then we've put through a couple of PRs (#4, #8) intended to address the problem of a node going unreachable but the routing logic not responding quickly.

Rendezvous hashing is a different approach to the same problem, where a hash of the key is combined with a hash of the node identity for each node, and the largest resulting number is the node that's routed to. Because it's computed on every request and is based on simple ordering, the cost of nodes entering or leaving is relatively small, and load is relatively evenly redistributed immediately.

There are other variants of it (skeleton hashing, CRUSH) that can offer better performance when there are large numbers of routable nodes (think a CDN) or multiple layers to the network structure, but neither of those apply for SpiceDB, where a large cluster might be 32 nodes.

This implements a rendezvous hashing strategy which can be configured at runtime. We'll need to run this against actual workloads to compare its behavior.

Changes

• Add a new implementation
• Add the ability to switch between implementations
• Add a benchmark comparing the two implemetations
• Update README

Testing

Review. Pull into a build of SpiceDB and observe its behavior.