Simplify transaction starting constraints to match reality

[inexorabletash]

All implementations have a strict ordering of transactions with overlapping scopes; read-only transactions can run in parallel but block a later read/write transaction from starting, and the read/write transactions similarly block later read/write and read-only transactions.

Tighten up the constraints definition to something precise, and move the wordy implications into a non-normative aside.

Also, define "overlapping scopes" as a term.

Closes #253

The following tasks have been completed:

• [x] Confirmed there are no ReSpec/BikeShed errors or warnings.
• [x] Verify existing WPT coverage, or add it

---

Preview | Diff

[inexorabletash]

Re: 1 - agreed. Web Locks in theory has that level of detail. I'd like to get that here at some point. A later PR, though. :)

Re: 2 - that's easy to add.... and great to document; I'd missed that WPT PR.

[inexorabletash]

I added normative text:

Implementations may impose additional constraints. For example, implementations are not required to run non-overlapping read/write transactions in parallel, or may impose limits on the number of running transactions.

The reason being, up in the lifecycle section it says:

When an implementation is able to enforce the constraints for the transaction’s scope and mode, defined below, the implementation must queue a task to start the transaction asynchronously.

... which seems reasonable as the starting point for a more rigorous algorithm (per #291).

[asutherland]

Looks great, thanks! Your continued evolution of the spec is greatly appreciated!

[inexorabletash]

Tests are in. Merging.