Martin vs. client compatibility: ideas for higher level testing

[michaelkirk]

After quite a journey, I have martin converting MVT to MLT that works on web and native (iOS).

There's still some fixes outstanding, but briefly:

1. clients need to send martin an appropriate Accept's header (this is expected, but should be made easier)

The rest of these are more like bugs:

2. js made some incorrect assumptions about encoding (merged)
3. native doesn't handle fastpfor yet. (rumor has it it's coming soon)
4. mlt-rust ignores it's config allow_fpf (bug, I'll open a PR for)
5. native expects presence fields in some circumstances in which rust omits them (I'm not sure if this is a bug in native, but I'll propose a new config option for martin which forces presence columns for compat. I'm not sure if this will be accepted.)
6. native expects encoding: mlt in tile.json, but martin can't produce this (I've opened a bug in MLN, but am currently working around it via a local hack in martin for now. I'm not sure if any long term martin change is warranted.)

If I had to guess, I'd say historically the martin devs are working more with the web client than native, since web was relatively smooth to get working. There are a lot of moving parts, and it's fairly new code, so I'm not surprised there are issues, but as the spec and clients continue to change, it'd be nice to have some higher level tests asserting that martin actually works with real clients, and if non-default config options are required for this, it'd be good to have something to point to.

Converting mvt -> mlt is kind of a nice use case, because you can use a static mvt.pmtiles, while still exercising the latest mlt encoder+options.