Clarify that IndexedDB's consistency model is strict serializability

[taymonbeal]

This is implicit from the algorithms in the spec, but this is such a foundational question for any kind of distributed database (even distributed among tabs on a user's machine) that it'd probably be good to state explicitly in some non-normative text. (Maybe with a link to the Jepsen definition or something.)

[inexorabletash]

Despite being the editor on this spec, I wouldn't consider myself a database expert. So if anyone wants to suggest where to put a section like this, and what it should cover (e.g. ACID), please put comments here (or a PR...)

[amirouche]

Here is what I use so far:

(okdb-transaction-hygiene [symbol]) symbol? → symbol?

The parameter okdb-transaction-hygiene may be used to get or set transaction guarantees related to isolation, and consistency. The following symbols may be accepted:

• read-uncommitted
• read-committed
• snapshot
• serializable

ref: https://source.wiredtiger.com/10.0.0/transactions.html#transaction_isolation

Then a transaction is explained as follow:

(okdb-in-transaction okdb proc [failure [success]]) okdb? procedure? procedure? procedure? → any? ... ↑ okdb-conflict?

Rationales:
[...]

okvs-in-transaction describes the extent of the atomic property, the
A in ACID, of changes against
the underlying database. A transaction will apply all database
operations in PROC or none: all or nothing. When
okdb-in-transaction returns successfully, the changes will be
visible for future transactions, and implement durability, D in
ACID. In case of error, changes will not be visible to future
transactions in all cases. Regarding isolation, and consistency,
respectively the I and C in ACID, it depends on the parameter
okdb-transaction-hygiene.

Based and adjusted from https://git.sr.ht/~amirouche/okdb/