Unbind transaction boundaries from connection open/close

[mwatts15]

Problem

The connection boundaries in owmeta-core are tied to the transaction boundaries in owmeta-core through the use of traction.begin/abort/commit calls in the owmeta_core.data.Data methods. This presents problems when, for instance, we want to abort a transaction but closing the connection via Data.closeDatabase commits the ongoing transaction:

with transaction.manager, connect():
    result = do_something()
    if condition(result):
        raise Exception("nope")

contrariwise, we can just have unnecessary transactions which aren't clearly tied to our transaction manager, which is just confusing. In this piece of code, we have a transaction that's initiated but then implicitly aborted when the transaction manager does its thing:

with connect(), transaction.manager:
    result = do_something()
    if condition(result):
        raise Exception("nope")

Which could prove problematic when we're integrating with other schemes that may have to do some extra work in setting up a transaction.

Proposal

• Add an explicit transaction manager to Data objects with "explicit" mode enabled by default.
• Make use of the explicit transaction manager where we use transaction.manager now (mostly in owmeta_core.command.OWM and tests for that)
• Allow replacing the transaction manager created automatically with one provided to allow for integration with transaction managers that are set up some other way.

Alternatives

Considered letting this alone, but it actually becomes a problem when trying to allow for retrying user actions within the scope of a transaction since the implicit commit commits partial work, even when we raise an exception when our connection boundary is within our transaction boundary and the retry starts a new transaction.

Just removing the transaction.begin/commit/abort calls doesn't completely solve the issue since it still leads to subtle bugs that are only solved by carefully rearranging when connections are started and ended, but that's really fragile, confusing, and harder to use in the long run than explicit transaction boundaries with standardized context managers.