Improve performance by handling `ETag` headers

[CommanderStorm]

This Issue is something that I think BBox could copy from martin with relative ease.
I am motivated by the rigged benchmark in https://github.com/FabianRechsteiner/vector-tiles-benchmark/
This is not an active factor in said benchmark currently, but might become one if it is rerun.

Important

An ETag-header offers a way for the client to validate that the tile is still the same.
In prior versions, bbox did not have ETags.
In theory there could be a difference in behavior with regards to tile refreshes, how CDNs/Reverse proxys cache content or how you do accounting if you are a SAAS.

This optimisation enables

• CDN-style caching of requests,
• may improve how reverese proxys cache tiles
• may reduce network bandwith and time spend downloading tiles a bit

It might be particularly noticable in usecases with slow networking such as on mobile.

Adding ETag-header handling to bbox (for tiles, not just static files).
If your device caches tiles, it will attach an If-None-Match-header with the expected ETag.
If bbox notices that the tile would match this ETag, we will send a 304 Not Modified.
Your device now skips a bit of network bandwith and time downloading tiles.

In some cases, the tile backend like .mbtiles this is already storing tiles with some hash.

Note

This change is not free in a few cases, in most it is.
On the martin project we hash (with a noncryptografic hash function) over all tiles.

Concretely, this means that while response times are the same, we can now deliver 5% less tiles per second in stress tests (f.ex. 206k to 197k requests per second) due to the slightly increased CPU load.
We have plans on the way to skip this work in some cases, but those have not made it into this release.

Here is the benchmarks we did and here is an issue maplibre/martin#580 listing the optimisations we have not implmented

Martin PRs for inspiration:
maplibre/martin#1836 maplibre/martin#1834 maplibre/martin#1787