Use ConcurrentLinkedQueue instead of CopyOnWriteArrayList & CopyOnWriteArraySet.
simplify assertion - to prevent iterating collection twice
fixing shutdown time
Cycle detection algorithm micro optimizations.
At cycle detection, replace condition in loop by a while(true), thus making the loop faster.
Remove ControllerHolder
(for performance tests purposes)
Fixing 'state' field and 'getState()' method visibility issues
Clean up and refactor a bit.
fixing bug introduced in previous commit
At ServiceBuilderImpl.install: check for the length of arrays against zero, instead of checking if those arrays are null.
At ServiceControllerImpl.transition, remove all double checks for a state, i.e., if the current state is STARTING or UP, it cannot be STOPPING and there is no need to check for that.

These checks were useful when they did more than check for state, now this became obsolete.
Removing Arjuna integration
Implemented Rs/W transactions idea. See attached IRC log bellow for more details:

<dmlloyd> I wonder if maybe we should have read-only transactions too, for query operations
<dmlloyd> because those we can have many of at once
<dmlloyd> and we could use upgrade/downgrade operations as well

<dmlloyd> was thinking a little bit about a txn api to go with our discussion yesterday
<dmlloyd> if we had: interface ReadTransaction { ... }, interface UpdateTransaction extends ReadTransaction { ... }
<dmlloyd> we could confine each operation based upon whether it is update or read/update
<dmlloyd> then the transaction controller API would have methods like: void startReadTransaction(Listener<ReadTransaction> listener);
<dmlloyd> void startUpdateTransaction(Listener<UpdateTransaction> listener);
<dmlloyd> void downgradeTransaction(UpdateTransaction transaction, Listener<ReadTransaction> listener);
<dmlloyd> boolean upgradeTransaction(ReadTransaction transaction, Listener<UpdateTransaction> listener);
<dmlloyd> internally there could be some kind of queue
<dmlloyd> each item in the queue can be a single waiting updater, or a set of waiting readers
<dmlloyd> opening a read transaction -> if the queue is empty and the current txn is read, join readers, else look in queue:
          if tail of queue is a set of readers, join it, else add a new reader set to the end of the queue
<dmlloyd> opening a new update transaction -> if no transaction is active, open, else add a new updater to the end of the queue
<dmlloyd> downgrading -> invalidate current UpdateTransaction object, convert current update txn to read txn;
          if head of queue is a set of readers, dequeue allow all readers in the set to join the transaction; return new ReadTransaction
<dmlloyd> upgrading -> if queue is empty, add updater to queue with same txn object as the current reader & return true, else return false (cannot upgrade)
<dmlloyd> in the upgrading case the user could still use the same ReadTransaction object (it is harmless to do so)
<dmlloyd> in the downgrade case we probably don't want to do that since only the Update half of the interface will be invalidated
<dmlloyd> the downgrade method could return the ReadTransaction directly though instead of going through a listener, since there is never a wait to downgrade
<dmlloyd> also, downgrading should only be possible if no update actions have occurred
[MSC2-6] Downgrading an update transaction should retain its position in queue
[MSC2-7] Upgrading an already-upgraded transaction should return true
[MSC2-8] enhancing TransactionController transaction lifecycle methods signature
Eliminating useless PrepareResult.isPrepared() method
Eliminating useless getRollbackReport() method
Eliminated abort and rollback phase usages from test suite.
Eliminating CancellableContext