Avoid unrotating due to programmatic rotation, even programmatic rotation that might expose empty portions of the map. Only snap to north due to a gesture.
This adds support for using cached styles that are stale. They're treated like changing styles; when the refreshed style changed compared to the one we've already had, we're swapping out the entire style, which might cause a slight flicker.
If you use many different caches, expired weak_ptrs will pile up in the unordered_map, but that is an edge case, and you probably shouldn't do that anyway.
Cleaned up gesture recognizers, flipping the origins of anchor points only and always before calling mbgl methods. This exposed the fact that the cursor locking feature during drag-zoom/rotate/tilt was broken, so I fixed it to match MapKit behavior exactly and also account for modifier changes in mid-gesture.
All Transform methods that take a PrecisionPoint now assume a “flipped” origin at the upper-left corner of the view. Previously, some methods assumed an origin at the lower-left corner.
Eliminated many redundant methods on Transform. Minimized usage of TransformState::x and TransformState::y. Added convenient constructors for AnimationOptions. When scaling, passing in view’s origin as the anchor no longer anchors the scaling operation at the view’s center. To specify no anchor, use NaN.
Increased precision of worldSize(), now that it’s used much more heavily in transform methods.
I regenerated assets.zip so that all file paths have an `assets/` prefix, as the Android AssetFileSource implementation asserts, and removed `TEST_DATA` from the paths.
* Move asset:// URL handling to DefaultFileSource.
* AssetFileSource implements FileSource interface and follows familiar implementation patterns.
* Move default implementation to platform/default, zip implementation to platform/android.
* Don't bother with modified / expires / etag -- assets are not cached so it doesn't matter.
* Don't bother with interleaving individual IO calls on the implementation thread. That adds a lot of complexity for very little benefit.
In the cache response case, we don't want the failedRequests logic; cached errors, should they occur, shouldn't affect the scheduling behavior for real requests.
We already had a condition that checks if a response is immediately available for an incoming request. Call the callback there, rather than in addObserver.
