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.
SQLite REPLACE is *not* UPSERT. If a conflict occurs, it first deletes the existing row, then inserts a new row. This means that AUTOINCREMENT primary keys change. This will break foreign keys to that value, which we use.
Instead we must try an UPDATE, and fall back to an INSERT if the UPDATE changes zero rows.
The run loop will be kept alive because it has an `AsyncTask`. We
also can simple stop the loop with `uv_stop()`.
The `RunLoop` is still gonna be the last object to be destroyed
because it is the first object to be created in the thread, so
by design it won't outlive `Timer`s and `AsyncTask`s.
This patch won't change the current behavior, will just make
the code simpler.
If we don't do this, we can activate a request twice.
The issue here is that we use memory address as the 'key'. So if
we destroy a request, another request might take the same memory
address, or the same 'key'.
The entry at 'pendingRequests' survives the 'cancel()' and is
ultimatelly removed at 'activatePendingRequest()'. This is fine
unless a request is created using the same 'key' before we call
'activatePendingRequest()'.
The check if the request was canceled at 'activatePendingRequest()'
will be no longer valid, activating the request. At the same time
the request will be activated again by the task scheduled at the
constructor of the 'OnlineFileRequestImpl' class.
This results in a ~1% increase in database size, which is worth it for reducing complexity and making the tiles and resources tables more similar in structure.
* Under the hood, SQLite creates surrogate keys (ROWID) anyway. We may as well take advantage of this and use the surrogates for foreign keys as well, since they are simpler and more efficient than compound foreign keys.
* Create indexes for efficient eviction queries
When inserting an cached resource, or removing a region, remove least-recently used resources and tiles, not used by offline regions, until the used database size, as calculated by multiplying the number of in-use pages by the page size, is less than the maximum cache size minus 5 times the page size.
In addition, OfflineDatabase may be configured to ignore cache puts of individual resources larger than a certain size.
This policy is similar but not identical to the former SQLiteCache policy:
* It accounts for offline, by exempting resources required by offline regions from eviction.
* It must delete from two tables (resources and tiles), rather than one. Currently the strategy is naive: evict 50 rows at a time from each table.
* It makes maximumCacheSize and maximumCacheEntrySize completely independent. The SQLiteCache implementation evicted when `usedSize > maximumCacheSize - 2 * maximumCacheEntrySize`. This evicts when `usedSize > maximumCacheSize - 5 * pageSize`.
* It uses a non-unlimited default value for maximumCacheSize: 50 MB. We should have always had a limit in place; "a cache without an eviction policy is a resource leak".
This allows the FileSource interface itself to support revalidation. We could (and probably should) now rewrite HTTPContextBase implementations as FileSource implementations.
