feat: mbtiles hash extraction support

[CommanderStorm]

(PR is based on #1786 => merge said PR first before looking at this one.)

This PR adds support to the mbtiles crate to hand out which hash corresponds to a tile.

The flat case might be debatable: Here I chose to md5 hash it to make upstream code more readable. The alternative would be to in this case return None for the hash.

This looks more intimidating than it actully is. Most of the lines are unit-tests.

[Copilot]

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

[nyurik]

we really ought to just generate our own test files - perhaps have a short SQLite script that fake-creates a few mbtiles with well understood properties. This way instead of checking in binary blobs, we can check in and generate these files on the fiy, and have an easy to inspect SQL that shows what they have.

[CommanderStorm]

Agree that generating test files might uncover bugs.
Here we are handling this too simplistic for example.

We are trusting that the metadata is actually valid.

[nyurik]

yep, and actually generating sqlite files should be very simple - we can just use the .dump command in sqlite to export the content of all existing files, delete the originals, clean up the generated dumps, remove any unrelated stuff from them, and use them to generate .mbtiles files during testing - e.g. with some extra init-mbtiles just command to set them up in some build dir.

[nyurik]

this looks good, but I don't want to merge something that is not being used, i.e. dead code -- can you add usage of the new fn to martin itself?

[CommanderStorm]

This is not actually dead code... mbtiles is a libary

The actual PR implementing ETAGs is a bit messy and needed another refactoring round before being an PR.
I would like to not merge them, to keep this reviewable.

We can leave it open and merge once I get to finishing that work.

[nyurik]

fair enough, lets merge, and thanks!