Mapbox-gl-native: Prioritise regular requests above offline download requests

[tobrun]

This issue covers prioritizing all regular requests, i.e. all requests necessary to show the current map view, above offline download request. This should resolve the issue outlined in https://github.com/mapbox/mapbox-gl-native/issues/11461.

[lilykaiser]

Capturing from internal conversations that several customers have now asked for this. @kkaefer do you think anyone from the GL team might be able to pick this up before our next release?

[dylan-chong]

This issue is a high priority for us as well. Has there been any progress on this issue?

[lilykaiser]

Thanks for reaching out @dylan-chong , we are waiting for a team member to free up so they can take a look at this. When we have a solution in place we'll link the PR here!

[chaupow]

Taking a stab at this. Copying some super helpful pointers from @ChrisLoer from chat ✨

• file_source.hpp defines the abstract interface that different file sources implement. I _think_ you’d want to add some sort of prioritization flag (with a default value of “high”?) to the request method there.
• online_file_source.cpp is the cross platform part of the “get stuff from the internet” FileSource implementation. (It in turns wraps HttpFileSource which has platform-specific implementations — I don’t think you should have to worry about the platform-specific parts.
• OfflineDownload manages queuing all the (very many) requests for tiles that we want to save for offline viewing, and then saving them to a local database when the requests complete. The queueing happens by calling ensureResource, which calls into onlineFileSource.request — this is where you could choose to mark your request as lower priority.
• OnlineFileSource::Impl maintains activeRequests and pendingRequests queues — I think this is probably where you’d want to implement the lower priority queue. So as it works now OfflineDownload will always try to queue up requests as long as it has fewer than 20 (e.g. HTTPFileSource::maximumConcurrentRequests), so it’s going to tend to fill up the activeRequest queue. New requests coming in from interactive tile loads will mostly get put in the pendingRequests queue, and they’ll basically have to keep competing with new requests coming from the OfflineDownload. So it’s fine for OfflineDownload requests to immediately go to the active state if there’s open connections available, but the thing we want to make sure is that any “high priority” queued requests in pendingRequests get moved to activeRequests before any further requests from OfflineDownload.
  

[friedbunny]

Fixed by #13019, which is available in android-v6.7.0-alpha.2, ios-v4.6.0-alpha.2, and friends.