When using sticky transactions calling clustered EJBs, user transaction currently uses a non-clustered
proxy which means that UserTransaction (UT) calls will always land in the same node. This has a bad side effect in the case
of dealing with clustered transaction sticky EJBs.

If the UT and EJB calls landed on the same node, everything works fine: no matter how many EJB calls are
done within a UT, they're all part of the same UT.

If the UT lands on one node but all the sticky EJB calls land on a different node, each EJB invocation is effectively
treated as a separate transaction because the tpc (transaction propagation context) does not exist in that node.

UserTransaction needs to be able to be deployed with a clustered proxy that supports sticky transactions in the sense that:

• Wherever ut.begin() lands, the EJB invocations within it and other ut operations (ut.commit(),ut.rollback()...etc) must
  land in the same node.
• Consecutive ut.begin() calls are free to land on different nodes, based on what the lbp is. For example, in the case
  of TransactionStickyRoundRobin, the next ut.begin() call will land on the next node in the view of the cluster.