Implement 'smart' setStyle using diff-and-patch technique

[anandthakker]

tl;dr: port smart setStyle from GL JS.

@jfirebaugh @lucaswoj @mapbox/gl here's my thinking after my (very) initial digging around the gl-native world. Feedback of course very welcome -- my hope is to dive in and start making a mess mid-next week.

Motivation

• Force a helpful refactor making mbgl::Style independent of mbgl::Map
• Provide an alternate path for paint-class-specific properties, which are now deprecated in the style spec, GL JS, and the iOS SDK.

Plan

• Make mbgl::Style independent of mbgl::Map
• Introduce 'nested styles', or some alternative.
  • Reason: on its own, a smooth setStyle implementation is not a complete replacement for paint classes. The problem is that the Style can accumulate state--e.g., by way of runtime styling or GeoJSONSource#setData()/mbgl::GeoJSONSource::setGeoJSON. With paint classes, it's very easy to have a set of basemap layers with alternative styling for, say, 'day' and 'night' and some interactive layers on top of it. Nested styles doesn't address the GeoJSON source part, but see below under "Design mbgl::Map::setStyle".
• Expose means to create independent style in SDKs
  • iOS/macOS (related: Initializers for MGLStyle #6386)
  • Android
  • Qt
  • RNMBGL
• Design mbgl::Map::setStyle(Style, ...?)
  • How should this handle Sources that carry state? (See Option to keep certain styles and layers on setStyle() mapbox-gl-js#4006 (comment))
• Implement mbgl::Map::setStyle() using diff-and-patch method and expose it in SDKs
  • Not having dug into this yet, it seems like a clean way to do this would be to diff the given Style against the map's current one, and then apply the necessary operations to the current one. But doing it this way, it might be weird that after calling map->setStyle(nextStyle), nextStyle won't refer to the map's actual style object.

---

Related: Efficiently apply style changes #2445

[jfirebaugh]

Are "nested styles" necessarily a dependency of the other work here? If possible let's decouple that. They're both going to be pretty challenging on their own.

it might be weird that after calling map->setStyle(nextStyle), nextStyle won't refer to the map's actual style object.

What would it take to make that happen? It seems like it might be possible to transfer ownership of the internal data that sticks around (tile and bucket objects) to nextStyle.

How should this handle Sources that carry state?

For now I don't think we should try to preserve any GeoJSON state that isn't present in the incoming style.

[anandthakker]

For now I don't think we should try to preserve any GeoJSON state that isn't present in the incoming style.

I think this may present a performance issue. If a GeoJSON source has a large literal value, then setStyle would have to either (a) do a fresh setData() every time or (b) do a deep equality check to determine whether or not the call to setData() is needed.

[anandthakker]

Update: per chat w/ @jfirebaugh and @lucaswoj , removed "nested styles", to be discussed/developed separately.

This was not a strict prerequisite for 'smart setStyle', but this or some alternative would be necessary in order for setStyle to be a genuine, reasonably-usable replacement for paint classes -- particularly when used in conjunction with a lot of runtime styling or dynamic data.

[jfirebaugh]

Looks like we're going to get this as a byproduct of #8820.