Add alternative TransactionProvider that implements ThreadLocal semantics

[lukaseder]

It is a frequent requirement for users to implement ThreadLocal transaction semantics in a way that a thread that starts a transaction will automatically get the same transaction / JDBC connection while within that transaction, without needing to access some locally scoped Configuration.

This was also criticised in the past by @witoldsz, author of ULTM, a transaction API that remedies this problem by offering an alternative API:

// jOOQ 3.8:
ctx.transaction(config -> doSomething());

// ULTM:
txManager.tx(() -> doSomething());

The criticism was valid at the time, although the current API is correct from a strategic point of view, as it does not depend on thread locality, which is essential in case we ever implement asynchronous, non-thread bound transactions. The current API never excluded resolving this confusion later on, and jOOQ 3.9 might be an appropriate time to add additional API:

• New DSLContext.transaction(() -> doSomething()) API
• A new TransactionProvider that implements ThreadLocal semantics
• A mechanism that ensures that the new API can only be called with a TransactionProvider that supports thread locality

---

See also:

• Two DataSources witoldsz/ultm#3 (comment)
• https://groups.google.com/forum/#!searchin/jooq-user/ultm

[lukaseder]

Prior to releasing this feature, I've renamed the new functional interfaces that wrap transactional code from ThreadLocalTransactionalXX to ContextTransactionalXX because that name will not suggest that a ThreadLocal is used as an implementation to supply that context.

As discussed here 6e35df8#commitcomment-20243406, a future jOOQ version will improve the current implementation for users to be able to implement their own context providing TransactionProvider implementations.