Introduces "optional" requests. These should be fulfilled by the FileSource only there's a low-cost/easy way to obtain the data (e.g. from a local cache). If the data for an optional request cannot be found, it *must* return a Response object with a NotFound error.
Traditional "required" requests still work the same way, with one change: If you set any prior* field in the Resource (i.e. priorModified, priorEtag, or priorExpires), the DefaultFileSource assumes that you already have the cache value and will not consult the cache before performing the request. If a prior cache lookup didn't turn up any data, and you therefore don't have an Etag or Modified value, you can still skip the cache by setting priorExpires. This will of course always result in a non-conditional HTTP request.
There's no need to do the work that OnlineFileRequest does on a separate thread from the DefaultFileSource thread, and having AsyncTasks proxy to other tasks across a thread boundary adds needless complexity.
The migration was upgrading the schema, but not the schema version. As a result, the (expensive) migration was running every time an OfflineDatabase was constructed with a v2 database.
Fixes#4501
This new code can be used for rendering on the Main thread
while it will also work for rendering on the Map thread
before we make the switch. Needed by #2909.
The tile limit guard (when used) stops a download from continuing
when the tile limit is reached. This wraps the guard in a method
and employs it in both places currently necessary to ensure the
guard has a chance to function. Tests have been updated to
ensure the fix works for a less trivial tile limit scenario.
The core of the change is ensuring that ensureResource doesn't release Zalgo: it should be consistently async, rather than async in the case that the resource doesn't exist in the database, but sync if it does.
This ensures that status is reported in a more consistent sequence, regardless of the database state.
If the server keeps sending replies considered from the client in the
past (there is no way to tell if the server or client clock is wrong),
the client will try to interpolate a valid expiration time based
on the delta of the expiration intervals sent by the server.
If the intervals are always the same, exponential backoff kicks in
until we get a different expiration time from what we already have.
When we receive an expired tile, we don't immediately retry
because in case the server keeps serving an expired tile, that
would cause an infinite retry cycle.
Now we add an exponential delay, similarly to what we do for
connection errors.
