Prevent enlisting additional resources on EJB caller side in case of server side RequiresNew

----------------------------------------------------------------------
Why does the customer need this? (List the business requirements here)
----------------------------------------------------------------------

We cannot afford an additional unnecessary resource enlisted on the caller side when calling a SSEJB through its remote interface, when this SSEJB makes no use of the caller transaction anyway (e.g. it uses a TransactionAttribute RequiresNew). Indeed, this typically makes the caller's transaction go 2PC, with at least the below negative consequences:
1. A potential performance hit on the client because the other client resource needs to go through a full 2PC completion sequence prepare + commit, while a One Phase Commit Optimisation would have been sufficient
2. More importantly, it makes client transaction completion depend on the painful asynchronous XA recovery mechanism in case something goes wrong in the 2PC. The asynchronous nature of this recovery can even have devastating effects: think for example of a single-threaded MDB dequeuing and enqueuing messages (against the same resource), with the requirement that messages must be processed in order. An asynchronous (delayed) transaction completion can cause ordering inconsistency.
3. Not to mention resources that do not actually support 2PC but still implement the XA interface (this is for example mandated by the JMS/JCA specs. for transacted inflow messaging) - those might shout (even fail?) upon being asked to prepare().

------------------------------------------------------------------------------------
How would the customer like to achieve this? (List the functional requirements here)
------------------------------------------------------------------------------------

We would like an optimization by which, if the EJB called does nothing with the caller's transaction (e.g. the EJB uses a TransactionAttribute RequiresNew), then no additional resource is enlisted on the caller's side.
This is already described by RedHat in discussion [1]/[2].

[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-January/004725.html
[2] http://lists.jboss.org/pipermail/wildfly-dev/2016-February/thread.html

------------------------------------------------------------------------------------------------------
Does the customer have any specific timeline dependencies and which release would they like to target?
------------------------------------------------------------------------------------------------------

No specific timeline dependency.