MODE-1819 Changed how WorkspaceCache is used inside user transactions

Added a new specialization of WorkspaceCache called
TransactionWorkspaceCache that is used in place of WorkspaceCache
any time a ReadOnlySessionCache or WritableSessionCache is used
during the scope of a running user transaction.

Normally, each RepositoryCache instance has for each workspace a
single WorkspaceCache instance shared by all sessions. However, in
the case of a session is running within a user transaction, it is
possible for the session (or other sessions that are also participating
in the same user transaction) to persist node changes in the document
store but to not commit the transaction. This means that such
persisted-but-not-committed node representations should be visible to
the sessions running within the transaction but should not be visible
to sessions outside of the transaction. Because the shared
WorkspaceCache lazily loads the requested nodes using the transactional
scope of the requestor, this means that the WorkspaceCache may load
these persisted-but-not-committed node representations and make them
available to other sessions (outside the transaction boundary) and
thereby leaking transactionally-scoped data. Similarly,
a WorkspaceCache that already has the persisted-and-committed node
representations from other sessions will expose those already-cached
forms to sessions running within the transaction, thereby causing
some of the sessions in the same user transaction to not see the
transactionally-scoped (e.g., persisted-but-not-committed) changes.

Therefore, such sessions running within user transactions need a
transactionally-scoped WorkspaceCache instance rather than sharing
the commont WorkspaceCache instance. However, the ModeShape
infrastructure is not set up to handle lots of WorkspaceCache instances
for the same workspace, so we have to be careful about any
transaction-specific caches.

This new design changes the AbstractSessionCache to maintain the original
reference to the real (shared) WorkspaceCache, but to also have another
WorkspaceCache reference that may change (depending upon whether there
is a current user transaction) to a transient TransactionalWorkspaceCache
instance specific to the transaction.

Originally, I tried to have the TransactionalWorkspaceCache do no
caching whatsoever, but this caused problems within the
WritableSessionCache's persistChanges logic, which needs access to
the persisted representation of the node prior to when each changed
node was actually changed. So, the TWC simply uses an in-memory
ConcurrentHashMap. (The alternative was to use another Infinispan
cache such as the one used for the shared workspace caches, but this
would dramatically increase the complexity of the system and would
require an additional cache container configured with different settings
than the normal workspace caches and to use a different naming
convention.)

Several new test cases were added to verify that multiple sessions
within the same user transaction do indeed all see the same
transactionally-scoped data, while other sessions that are outside
of the user transaction do indeed not see any of the transactionally-
scoped changes until commit occurs.
MODE-1822 Added tests that use Atomikos transaction manager

Other fixes for MODE-1819 actually fixed the problem, while this
change only adds test cases and test dependencies on Atomikos to
verify the expected behavior now works. Also added similar tests
that use the JBoss Transactions library.
MODE-1823 - Changed the rest service's output mechanism, so that the written strings are always UTF-8 encoded and added UTF-8 as an explicit response header.
MODE-1823 - Fixed the WebDAV servlet to use UTF-8 encoding in paths and also to generate full links when displaying the contents of folders.
MODE-1827 - NullPointerException in RepositoryQueryManager

Null check in case the node no longer exist in the cache.
MODE-1828 - ConstraintViolationException when updating the definition of the same node in a session

Fix the issue by making sure that nodeTypes with the same name is actually updated properly in the cache.
MODE-1826 - Added an integration smoke test which uses a write-behind, JDBC cache store
MODE-1826 MODE-1769 MODE-1763 Temporarily ignored the JDBC smoke test
MODE-1829 Re-enabled several query tests
MODE-1830 Corrected the purging of workspace caches in a cluster

Before this fix, when a change was made via a WritableSessionCache,
any changes persisted to the store were also used to directly purge
any previously-cached node representations from the corresponding
WorkspaceCache. Thus, when the RepositoryCache received the changes,
it simply forwarding them to all workspaces except the one in which
the changes originated.

However, in a clustered environment, the changes originate on one
process and are sent to all other processes. The logic described
above works fine in the same process in which the changes originated,
but it doesn't correctly propagate the changes in the other processes.

The fix was pretty simple: determine if the changes came from the same
process. If so, the use the current logic. If not, always forward the
changes to all WorkspaceCache instances.

I also modified the ClusteredRepositoryTest to look in process A for
nodes changed in process B. This failed before the logic was fixed,
and now works with the fix.
Updated release scripts to deal with JIRA accounts that have no last name
Update bin/jira.py