Is it necessary to reload tiles on setFilter() change

[scarletjohansson]

When a layer filter is changed via setFilterTiles, all of the tiles are currently reloaded (meaning going through source cache and into the worker and back). Is this actually necessary, or just an artefact of over-invalidation on the call to _update()? I am not that familiar with the FeatureFilter code, but from scanning it I couldn't really find a reason why the cached version of the tile is actually modified / destroyed in the process of filtering. It seems to me like what is in the cache should still be okay, and it's just the buckets that need to be rebuilt with the new filter.

This might seem like a small detail, but it can be really for more complicated tiles... this can really end up spending a lot of time in WorkerTile.parse (rebuilding the feature index?).

It would be nice to be able to use the filters for somewhat dynamic purposes, I know that probably requires rebuilding the OpenGL geometry on the browser side, but in my profiling measurements that seems to be much less costly than the worker-side computation happening in the tile reload.

@anandthakker @mourner

[jfirebaugh]

"Reloading" the tiles -- going through the worker and back -- is what rebuilds the bucket, so yes, it is necessary. We do have some ideas for the future about how to make it cheaper, primarily #4576. We also have several tickets tracking setFilter performance -- #2874, #2443. Closing this one as duplicate.