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:

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

---

Preview | Diff

[asutherland]

This is a really fantastic cleanup!

Two thoughts:

1. The more straightforward constraints seem to increase the importance of "created" and the ordering it creates. At a surface reading, this might suggest there's a global clock across agents and agent clusters and that supersedes any IPC/spec tasks. We only get into "queue a task" in step 2 of the lifetime when starting the transaction. I'm not sure this demands the full task treatment, but maybe some normative text about the creation order being that as perceived by the underlying implementation task queue?

2. I think it would be helpful for the spec to make it clear that implementations are not required to run non-overlapping read/write transactions in parallel and that indeed, some implementations do not. For example, we landed a fix in web-platform-tests/wpt@c786945#diff-9896d580c9b272443f82b9268b2fc226 where a commit() test case was depending on implementations to do this. It would seem to make sense for this to live around the "These constraints imply the following" section, if not directly in that section. Phrasing gets tricky with a negation, so maybe just an extra info box like "Note that implementations are not required to run non-overlapping read/write transactions in parallel."

[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.