Multi-process shared-objects execution

[asonnino]

• Multicore execution of shared-object transactions
• Speed up unit tests that use Narwhal
• Fix underminist failure of a few unit tests

A bit of context on how this work. Upon receiving a shared-object certificate, the Sui authority first calls try_skip_consensus to see if locks already exist and it can directly re-attempt execution (without going through consensus). If it can't, it sends the transaction through consensus. After sequencing, consensus calls asign_shared_locks to assign shared locks to every shared-object in the certificate. Note that there is only one task running asign_shared_locks (this is safety-critical). Finally, the certificate returns to the Sui authority who calls execute_shared_transaction to attempt execution. Note that the order of the checks in the functions below are important to avoid race-conditions. Further, the shared-objects logic assumes that every shared-object transaction updates at least one owned-transaction (the gas object); this avoids a number of race conditions upon committing the transaction effects to storage.

[1 task per connection] try_skip_consensus:
1. If effects { return info }
2. locks_exist = Check shared-locks exist
3. If locks_exist { Check shared-locks; then atomically execute & remove shared-locks }

[only run by 1 task] asign_shared_locks:
1. locks_exist = Check shared-locks exist
2. If effects { return info }
3. If !locks_exist { Assign locks }

[1 task per connection] execute_shared_transaction:
1. If effects { return info }
2. Check shared-locks; then atomically execute & remove shared-locks

[asonnino]

CC @mystenmark to coordinate with #1953

[bmwill]

these don't need to be made pub as there are accessors implemented below for that

[asonnino]

I need to modify them to not use the default values (it was one of the reasons why our tests are so slow)

[asonnino]

Ideally we need a constructor for narwhal configs, but I figured this could be made in a separate PR (the config structure is pretty complex)

[bmwill]

Got it. Yeah this is something that we can fix later (enabling configuration generation with a base template)