Previously, when we started a worker operation that eventually throws an exception (e.g. due to the tile not being parseable), and then enqueue another worker operation while the first one is processing, we treated the worker as idle once the first operation's error callback fired, even though the second operation was still in progress. Due to our use of coalescing, I was unable to come up with a reliable test since we'd need to reproduce the behavior described above, which is timing dependent.
Since 9a9408e811, we marked tiles as non-renderable if an error occured. This lead to situations where a tile was loaded + parsed successfully, then a revalidation attempt occured (e.g. because the resource was stale) which failed. In this case, we used to mark the tile as non-renderable although we could've used the perfectly parsed (stale) resource.
* Eliminate updateBatch in favor of diffing layers and detecting changes to properties upon which layout depends.
* Replace RenderSource::{update,remove,invalidate,reload}Tiles with a single update method
* Replace TilePyramid::{update,remove,invalidate,reload}Tiles with a single update method
* Remove Style& dependency TODO from GeometryTile and TileParameters
Moves the following to the renderer directory and out of the style namespace:
* CascadeParameters
* PropertyEvaluationParameters
* UpdateParameters
* PropertyEvaluator
* DataDrivenPropertyEvaluator
* CrossFadedPropertyEvaluator
* PaintPropertyBinder
* PaintProperyStatistics
* PossiblyEvaluatedPropertyValue
* TransitioningLight
* EvaluatedLight
It should be safe to invoke GeometryTileWorker::setData multiple times without invoking GeometryTileWorker::setLayers. Therefore GeometryTileWorker::redoLayout() must not consume the layers.
