An implementation of a DurableEDNStore that uses Browser local storage to save/load the EDN.

A protocol for storing/loading EDN from some kind of durable storage. This protocol is used by the offline support
to isolate the need to persist data from the runtime environment, since Fulcro may be running in node/electron, a
browser, or a mobile device.

Support for durable mutations that can be automatically retried against a remote until a positive
confirmation of success is received, or a specific kind of error indicates it cannot succeed.

You must configure your application in order to use this support. In particular, a durable storage for the mutations
must be defined so that they can survive application restarts, power failures, etc.  Your implementation of that storage will determine
the overall reliability of these mutations. Additionally, you *may* define a custom optimistic tempid strategy that can do
tempid remappings before ever talking to the server.

The mutations in a durable transaction *must* be:

* Idempotent
* Order-independent

This system asserts that the mutation in question *will eventually* run. However, it exposes the details of
what is really going on at the mutation layer so that you can customize the behavior as needed.

IMPORTANT: The optimistic side of the mutation will run any time the mutation is tried. You can check (via
`durable-mutations/retry?`) if this is a retry, and decide if there is anything to do in the UI.

Optimistic temporary ID remapping is supported, but requires that you define a TempidStrategy.
This can be done by either pre-allocating a range from the server, or by allowing the client to use generated
UUIDs (i.e. the UUID within the tempid itself). *Your server must agree on this strategy for consistent operation*.

It is a valid strategy to *not* resolve the tempids on the client, in which case your app state will have tempids
on the items submitted until the real mutation completes. Tempid rewrites from the server are always applied, even
if you had previously remapped them on the client.

Server-side implementations of durable mutations cannot have any meaningful return value other than `:tempids` since
there is no guarantee when the real mutation will run.

There is a closure goog.define of BACKOFF_LIMIT_MS which defaults to 30000 (ms). This limits the maximum wait time between
mutation retries and can be modified via compiler settings. See compiler docs.

NOTE: The backoff will cause mutations to appear somewhat slowly when network communication resumes. This is by design,
and will prevent a flood of requests after a server outage. Caution: Setting this too low can cause blockage on retry
logic when the network is down.

There is also a LOOP_TIMEOUT_MS (default 20ms). Any durable mutation transact submission, on average, appear
to have this much latency. Setting it too low will cause the browser to waste a lot of CPU looking for trouble,
setting it too high will annoy the user. DO NOT SET THIS TO 0.

Installation: See `with-durable-mutations`.

Usage: Use `transact!` from this ns, or add `:com.fulcrologic.fulcro.offline.durable-mutations/durable? true` to the
options of your call to `comp/transact!`. Do not include follow-on reads in the transaction if using `comp/transact!`.

Support for a loading system that supports keeping previously-seen query responses in a persistent
cache. It supports the following features:

* Make a failed load return the last cached value.
** Support for a default value for the load in case you are offline and nothing is in the cache.
* Support for an eager/fast return from cache even when online.
** Indicating if the actual return should just go to cache, or both cache and app merge.

This support replaces the default definition of the `internal-load` mutation in your Fulcro app, and hooks
cache control into the normal load options (open map). If no caching options are given in a `load!`, then
it uses Fulcro's built-in implementation of load.

WARNING: Mixing this with durable mutations can be a problem. You should only use a load cache on
items that *cannot* be modified by durable mutations unless you're willing to also update the
load cache to reflect the mutation changes; otherwise the load cache can get out of sync with the
durable mutations and cause all manner of havoc. This facility is primarily about making well-known
data (e.g. inventory items, dropdown options, etc.) available even when the server is not responding.

Installation: See `with-load-cache`

Usage: Use the `load!` and `load-eagerly!` functions from this ns. Operations in `data-fetch` ns will continue to work
in an unmodified fashion.

Temporary ID strategy. Used by offline support to enable disconnected applications to define how Fulcro tempids
 behave when disconnected. The support allows a client decide to implement ID support in whatever way
 makes sense to the feature set of the application in offline modes.

 * Negotiate a pre-allocated pool of IDs with the server when online.
 * Use client-generated UUIDs
 * Use the UUIDs within the tempids as the real IDs on the server
 * etc.

This ns also includes two pre-written strategies:

TempIDisRealIDStrategy:: This strategy immediately rewrites the tempids in app state to the UUID *within* the tempid. This allows
the client to assign the real ID of the entity immediately, and the server must then either honor that assignment or remap it
on success. The server will receive the tempid. This is a very easy way to ensure idempotent save as well, since the
server can easily detect when that an incoming tempid has already been saved under that UUID in the database.

NOOPStrategy:: Does nothing. The IDs remain temporary in app state and in the txn sent to the server. Rewrites happen
on success.