Concurrency conflicts between Transaction- and ModelController

[cdamus]

The TransactionController can interact with the same resource sets, esp. for JSON (de)serialization, as the ModelController, on any number of different threads for incoming requests.

Whereas the ModelController by default has a wrapper that serializes all access onto a single thread, we need the same for the TransactionController. Moreover the ModelController and the TransactionController need to be coördinated on the same thread.

As the number of asynchronous requests coming in from client applications via the Model Server (Node) increases, the likelihood of ConcurrentModificationExceptions in the JSON (de)serialization increases with it, as well as problems reading an inconsistent state of a model being requested on GET /api/v2/models while some edit transaction is making changes to it.

[CamilleLetavernier]

Actually, I noticed an issue with the ModelSynchronizer. It doesn't check for re-entrant sync calls, so the Synchronizer thread can post sync-calls to itself (and wait for them), causing a deadlock.

It seems that this was already an issue in the original SingleThreadModelController, but it didn't actually occur because there were no such re-entrant sync calls. However, the TransactionController actually triggers such calls; so we need to add a thread-check in syncCall and syncExec, and simply execute the Runnable/Callable if these methods are called from the Synchronizer thread