Allow more explicit control over transaction lifetimes

[inexorabletash]

Imported from https://www.w3.org/Bugs/Public/show_bug.cgi?id=11528

Based on lots of developer feedback, in addition to the current automatic commit model it would be nice to support:

• explicitly committing, to avoid extra round-trips (known performance bottleneck)
• ways to defer committing to allow other async processing to occur within transaction scope

Both make the transaction model more complex, so we should tread carefully.

[inexorabletash]

My thoughts on both of these are captured in these gists:

• https://gist.github.com/inexorabletash/d55a6669a040e92e47c6
• https://gist.github.com/inexorabletash/8c122c84a65de65c35b3

[inexorabletash]

In addition, for many puts, the overhead of all the individual success events can jank the main thread. We may want to design this in such a way that the transaction just opts-out of the per-request events entirely - possibly put() and friends just return null in those cases!

[inexorabletash]

TPAC 2019 Web Apps breakout:

Looked at two proposals:

• On IDBTransaction add waitUntil(promise). Can be called multiple times. Try redefine autocommit behavior in terms of these promises resolving (i.e. unify requests and promises).
• On IDBDatabase.transaction() add an option manualCommit: true; commit() must be called explicitly.

Notes:

• Expect most usage to be by wrappers/libraries.
• Attendees were pretty split - explicit commit is more like traditional database APIs, promises build on SW/WebLocks patterns and reduce risk of coding deadlocks
• Using either option puts the transaction into a new mode where new requests can be made at any time.
• At first glance, seems like either option can be polyfilled on the other

Next steps: make concrete proposals; reach out to library authors to get feedback on preferences