Using the transaction counter optimizations more universally

[cpurdy]

We're shelving this for now (it's not critical path), but after the team call yesterday, we went through a few iterations on the idea that we discussed about having the composable concurrent transactions apply to other DBObjects besides the DBCounter, and here is what we came up with on the base DBObject interface:

// ----- transactionally composable operations -------------------------------------------------

/**
 * Perform a semi-blind test against the DBObject, and register the same test (along with the
 * result from running it) as a precondition for the commit (i.e. a "prepare constraint").
 *
 * This operation provides several capabilities:
 *
 * * First, it allows a test to be conducted on the current state of the data in the database,
 *   without explicitly enlisting _that exact copy of that state_. In other words, the test is
 *   semi-blind, because it does not return the data contents of the database to the caller.
 *
 * * Second, it registers the test and the corresponding result as a necessary precondition for
 *   the commit, such that changes to the database sufficient to change the result of the test,
 *   will result in the current transaction failing to commit (and thus rolling back). This
 *   method represents the only explicit way to dynamically register a pre-condition for commit,
 *   and as such can be thought of like a [Validator] -- except that a [Validator] must be
 *   declared in the schema and applies to every transaction (it is not dynamic), and this test
 *   may be parameterized, as long as all of the information that it captures is immutable.
 *
 * @param test  a function to evaluate immediately, which will return a Boolean to the caller,
 *              but which is also stored (along with that Boolean) as a precondition for commit
 *
 * @return the result of evaluating the function
 */
Boolean eval(function Boolean(DBObject) test);

/**
 * Perform a blind adjustment of the DBObject.
 *
 * A "blind" operation is one that is used to operate on the DBObject in a manner that is
 * transactionally composable, such that the invoking this operation would not itself cause the
 * current transaction to roll back, even in the presence of other concurrent transactions. The
 * prescribed implementation of this method is to defer its execution until the latter of (1)
 * any read operation on this same DBObject, or (2) the beginning of the prepare phase of the
 * transaction. By deferring the execution until the start of the prepare, the changes caused
 * by the function will come **after** any other transactions were running concurrently and have
 * since committed, and thus will not cause a roll-back to occur, even if those other
 * transactions altered this same DBObject.
 *
 * * The function must be freezable; it must not capture mutable references.
 *
 * * Access of, and changes to data from other `DBObject` is not predictable in terms of when
 *   it occurs; the guarantee of ordering is tied to this specific DBObject, and states simply
 *   that this operation will have occurred before any subsequent read operation against this
 *   same DBObject in this same current transaction is processed.
 *
 * * Subsequent non-blind operations against this same DBObject within the current transaction
 *   will destroy the composability of this operation, by forcing the execution of the function.
 *
 * @param process  a function that operates against (and may both read and modify) the DBObject
 *                 reference passed to the function (representing this DBObject)
 */
void modify(function Boolean(DBObject) adjust);

Then, the thinking goes, we could introduce more focused methods, i.e. less likely to be forced by a read. For example, on DBMap, we could add key-bound methods:

Boolean eval(Key key, function Boolean(DBObject) test);
void modify(Key key, function Boolean(DBObject) adjust);

Feedback welcome.

[cpurdy]

The method names and documentation have changed, but this capability is now included as part of the root DBObject. The implementation is in progress.