Private contract migration and offchain state sync

[grbIzl]

1. This PR addresses the following use cases:
   1.1) Client can setup the private contract in order to store its state locally in DB and store its hash in the contact only. This allows to use unlimited amount of data in the private contract (see TODO section for temporal limitation)
   1.2) Members, that have access to the private contract key, can be modified, new members can be added. In this case newly added members will request the state from the peers.

2. Usage of the offchain storage is regulated via command line startup flag --private-state-offchain. By default (if flag is not used) it's set to false (to use onchain storage).

3. Current private transactions usage scenarios were modified for the case of offchain storage

3.1) Private contract's deployment
If not all the states of private contracts required for the deployment available, deployment returns the error PrivateStateNotFound. Client has to repeat the procedure later (see TODO section for improvement of the usability)

3.2) Make changes in the private contract
Originator:
If some states are missing, originator's request saved, missing states requested
After receiving requested states, save them and fire stored originator's request

Verificator:
If during verification some states are not available, state requested and verification request saved.
After receiving actual state, save it and proceed with verification.

3.3) Read of the private state
If some state is not available, the same error is returned, client should try again later
Meanwhile state is requested, stored after retrieving

4. The following TODOs were omitted during the development

• Chunking for private state is not yet implemented. So the size of the state is limited by the maximum size of the packet [PrivateTransactions] Chunking for private state sync #10750
• Logging is not yet supported for this feature. [PrivateTransactions] Implement logging in case of offchain storage scenarios #10751

Closes #9198, closes #9201

[svyatonik]

Never reviewed anything private-tx related before, so left few questions/comments. Will do a final review once they're answered/addressed.

[svyatonik]

I don't think you actually need so many RwLocks - all the data seems to be logically connected. Like in this code:

(1)		self.state_storage.state_sync_completed(hash);
(2)		if self.state_storage.current_sync_state() == SyncState::Idle {
			trace!(target: "privatetx", "Private state sync completed, processing pending requests");
(3)			let creation_requests = self.state_storage.drain_creation_queue();

there are 3 calls which are using 3 different RwLock. And, for example, if check (2) passes (i.e. the state is Idle) and before line (3) someone adds more states to sync, drain_*() calls could actually return these new requests, for which states are missing => tx sign/verification will fail.

So probably reconsider API to avoid such issues (and leave <= 1 internal lock)?

[grbIzl]

Reworked. 2 locks are left. The second one is needed for stalling requests logic implementation (in order to keep currently processed hashes in the separate structure)

[ordian]

The logic looks ok to me, although I've never reviewed anything private-tx related before too.

[svyatonik]

lgtm

[svyatonik]

Not an issue, but probably some optimization for future PRs - there's a LinkedHashMap struct - I've used it in similar cases (for detecting stale requests) to avoid iterating the whole HashMap.