* Make tee not wrap PublishSubjects in SafeSubscribers, otherwise a non Rx exception from an unsafe observer shuts down all other observers under the same PublishSubject
* Throw SQLException or PersistenceException plain, that may come out of an unsafe subscriber
* Revert "Throw SQLException or PersistenceException plain, that may come out of an unsafe subscriber"
This reverts commit c7b8af3fa6.
* Update Detekt baseline
* Just passing in the exception was printing the entire stacktrace to the log, now we just pring the exception and message
* Updating exception message
* switch to new version of plugin
* change plugin version to force refresh
* try using pre-populated cache
* do not preallocate
* no daemon
* reduce cores per fork to increase parallelism
* even more aggresive cpu allocation
Observers registered on NodeVaultService#rawUpdates, if they throw an exception when called from serviceHub#recordTransactions and if this exception is not handled by the flow hospital, then this leads to the transaction not being recorded in the local vault. This could get the ledger in an out of sync state.
In the specific case this happens within FinalityFlow#notariseAndRecord this leads to the transaction being notarized but not recorded in the local vault nor broadcasted in any counter party. The -failed to be recorded locally- transaction and its output states are not visible to any vault, and its input states not able to consumed by a new transaction, since they are recorded as consumed within the Notary. In this specific case we need not loose, by any means, the current transaction.
We will handle all cases by catching all exceptions thrown from serviceHub#recordTransactions, wrapping them with a HospitalizeFlowException and throwing it instead. The flow will get to the hospital for observation to be retried from previous checkpoint on next node restart.
Use `flowId` from `ExternalMessageEvent` when failing to init sessions instead of generating
a new random UUID. The a `flowId` is generated and stored inside the event after the
state machine work that done previously.
Cap the default size of the external operation thread pool to 10 or
the maximum number of available processors, whichever is smaller.
Set the minimum size of the thread pool to 1. Meaning that only a
single thread is used unless the node actually starts to use
`FlowExternalOperation` which consumes threads from this pool.
