TileLayer improvements

[Pessimistress]

Resolves #3511

This PR refactors BaseTileLayer/TileCache classes to function more similar to Tile3DLayer/Tileset3D. Traversal now reruns every time any tile finishes loading, instead of waiting for the entire viewport to load. The logic that determines tile visibilities is entirely moved into TileCache. It also uses a more sophisticated strategy (configurable by the user) to pick placeholders when a tile is pending.

The new API needs audit.

Change List

• Add strategy prop to BaseTileLayer (see documentation)
• TileCache rewrite
• Unit tests

[coveralls]

Coverage decreased (-2.4%) to 80.872% when pulling 720f23d on x/tile-strategy into 49aac07 on master.

[ibgreen]

Got interrupted, will add more comments soon...

[ibgreen]

I feel that having classes named "Base..." should be avoided if at all possible. To me exposing abstract base classes is very technical, and associated with object oriented programming practices that are currently out-of-style (particularly in the JS community).

My preference would be to avoid the Base name and call this TileLayer instead of BaseTileLayer. Assuming that creates an unacceptable naming collisions (a layer with the same name in two different modules), happy to work on finding a more suggestive name.

I think this should still be in geo-layers - just because we make layers work with non-geospatial coordinate systems does not mean they automatically get moved out of geo-layers, at least this should not be in the core layers module.

If the 2D loader is getting this complicated, I am starting to feel it could make sense to put the TileCache code (which I want to call Tileset2D) in loaders.gl. We can expand the 3d tiles category to tiles handle both 2D and 3D tiles...

There seems to be a lot of overlap in logic, support classes, testing logic etc.

As one example, we are going to need to add support for the RequestScheduler from loaders.gl to this class as well, so there could be synergies by having this in loaders.

We just need to find a sub-module structure that makes sense to everyone.

[ibgreen]

Two way reuse, both up and down... This is not used by 3d tiles. Does this complicate things much?

[Pessimistress]

3d-tiles loads everything from the root to the current level, so the parent is always available when you zoom out. 2d only loads tiles at the current level. When you zoom out and no ancestors are available, the map will flash white and you lose all visual reference. Yes it adds complexity, but it's also needed for usability.

[Pessimistress]

Regarding the BaseTileLayer class: we need an API audit before 8.1 release for sure. If we are not moving it into the core layers, then there will be only one TileLayer as before, just exposing a few new props to enable the new use cases.

I'm ok with this arrangement for now, given this non-geospatial support is new. In the long term, do we want to investigate non-geospatial support for 3d tiles (e.g. Potree is technically not bound to geospatial)? If so, we may want to move these two layers to a new module @deck.gl/tile-layers and drop any specific format dependency?