Prioritize performance in vtile decoding

[springmeyer]

This moves the previously hardcoded v1->v2 upgrade and full tile recursion for vtile schema validation to opt-in (disabled by default).

This will unlock being able to render both existing v1 and future v2 tiles to images with AGG without an extra performance cost compared to node-mapnik v3.4.x (for this code path the spec version and v2 polygon validity don't matter).

• When validation and JIT migration of v1->v2 matter these options can be turned back on by the calling application.
• Layer version validation moved one level up because the validation code is currently agnostic to the spec version. The one case that was previously unchecked for v1 (LAYER_HAS_NO_FEATURES) makes just as much sense to check for v1 now that validation is an opt-in valid-add rather than something blocking the ability to decode an otherwise valid tile.

/cc @yhahn @jakepruitt @flippmoke @mapsam @GretaCB

Before merging:

• Code review @jakepruitt @flippmoke

[jakepruitt]

@springmeyer did you mean upgrade && version != 1? If so, I think we should probably just quietly ignore the situation of upgrade && version == 2, but probably throw or warn when upgrade && version == 3 or something along those lines comes up.

[springmeyer]

@jakepruitt - good eye, yes I did mean upgrade && version != 1 and therefore this code currently will throw when you try to upgrade a v2 tile, since that is pointless. But I agree that quietly ignoring this situation would likely be more convenient for calling applications. Otherwise they'd need to check the version themselves and toggle the option to avoid errors in mixed tile cases, which would be painful. So I will change to be quiet. Thanks!

[pnorman]

Looking forward to when v3 comes out, is this the best API?

If we have the same scenario where the vector tiles can be upgraded, there's no way to know if the calling application wants a v1->v2 upgrade or wants everything upgraded to v3.

[springmeyer]

Looking forward to when v3 comes out, is this the best API?

@pnorman - I've had the same thought during this code review: that this API is currently not a robust one for allowing fine grained control over upgrades going forward. But that is not something I'm working on currently, so I've attempted to make the minimal changes necessary in the pull to get the upgrade and validation behavior exposed as options.