Allow primary keys to contain address columns sorted by their resolved values.

[nicktobey]

This is the Dolt part of this change.

GMS PR: dolthub/go-mysql-server#2854
Doltgres PR: dolthub/doltgresql#1214

The goal of the change is to allow for indexes to use an out-of-line variable-length type (like TEXT or BLOB) as a primary key while still storing just the address in the index (instead of being forced to store a prefix of the value).

As a result of this change, any tuple comparison operation may need to resolve a hash in the NodeStore. This poses two complications:

1. The tuple logic exists at a much lower level than the node store and can't depend on it without creating a dependency cycle. We get around this with a new ValueStore interface that can store and retrieve variable-length bytestrings by their content hash. NodeStore is the only implementation of this interface, but decoupling the interface from the implementation allows us to not depend on NodeStore's internals when passing it to lower-level code.

2. Tuple comparison operations can now end up doing disk IO, which means they need a context parameter.

[coffeegoddd]

@nicktobey DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
6e715ae	ok	5937457

version	total_tests
6e715ae	5937457

correctness_percentage
100.0

[zachmu]

LGTM

[zachmu]

Could use a type comment

[zachmu]

Comments for this type and its methods

[zachmu]

Not really a criticism, but I'm not sure this is in the spirit of this method. I.e. if you have to deref an address to get the value to compare, this is probably going to be very slow, and the point of this method is to be faster than deserializing the values just to compare them.

Not really sure what to do about it though.

[nicktobey]

I suppose that for very large values we only need to load a single chunk at a time: they might differ in the very first chunk. But that would only work if the child handler has certain properties that we can't guarantee. I added a TODO.

[coffeegoddd]

@nicktobey DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
886e684	ok	5937457

version	total_tests
886e684	5937457

correctness_percentage
100.0

[coffeegoddd]

@coffeegoddd DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
53f404c	ok	5937457

version	total_tests
53f404c	5937457

correctness_percentage
100.0