HeadlessBackend seems to be part of the mbgl::gl namespace. Since OSMesaBackendImpl is only in the mbgl namespace this code does not compile.
Since this file is in the mbgl/gl folder I think it makes sense to just put the whole thing in the mbgl::gl namespace.
Refactor out HeadlessFrontend and HeadlessBackend gl independent code to gfx.
Define gl::HeadlessBackend as subclass, instantiated by gfx::HeadlessBackend static factory method.
GL dependent tests are still using gl::HeadlessBackend directly (not through gfx).
Add new APIs for invalidating tiles, effectively forcing Mapbox
GL Native to check with the servers if the tiles are valid before
using them. This is more efficient then deleting tiles, because
in case of valid tiles, they won't get downloaded.
Fixes#4376.
- Do not carry it over everywhere as parameter, it is a shared
instance anyway and the lifecycle is pretty much the app lifecycle
from the moment we instantiate a map.
- Rename to BackgroundScheduler because it is a Scheduler that will
do tasks in the background, we don't make assumptions if it is a
thread pool or a single thread.
- Most importantly, remove the dependency from `core` on `platform`.
At the moment, the annotations implementation in the `mapbox-gl-native`
core is creating concrete layer instances apart from `LayerManager/LayerFactory`
code path.
So, annotations must be disabled if the `LayerManager` implementation does
not provide line, fill or symbol layers (those, used by the annotations).
Note: in future, annotations implementation will be moved from the core to the
platform SDK level(see https://github.com/mapbox/mapbox-plugins-android/tree/master/plugin-annotation)
and `LayerManager` won't need to disable it.
`LayerManager` is now responsible for `RenderLayer` instances creation,
so that there is a single entry point for creating of objects, which
correspond to a certain layer type.
The `LayerType type` field is dropped from `Layer::Impl`.
The `LayerTypeInfo` contains static meta data about certain layer type.
Each layer module should have a single immutable `LayerTypeInfo` instance
for the represented layer type. Both `LayerImpl` and `LayerFactory` from the
module always refer to the same `LayerTypeInfo` instance, so address of this
instance can be used as a layer module Id during the process life time.
