[Move] Add shared mutable object support

[lxfind]

This PR adds support to use shared mutable object in Move.
Shared mutable object is not fully supported in Sui yet, as the sequencer is still being developed. However adding the support and library in Move will allow us to start writing interesting contracts using shared object.
This PR also writes a new version of TicTacToe that uses shared object, which provides an example for people to compare with the version that doesn't.

[666lcz]

Sweet, V2 is 100+ lines less than V1!

[gdanezis]

Quick Q on the systems side @lxfind : do we allow shared objects to be deleted? If so it makes the safety / liveness checks more expensive / complex. If a shared object can never be deleted then life is simpler.

[gdanezis]

Nice one! See question on delete & transfer!

[gdanezis]

Do we allow shared objects to be transferred?

[sblackshear]

Quick Q on the systems side @lxfind : do we allow shared objects to be deleted? If so it makes the safety / liveness checks more expensive / complex. If a shared object can never be deleted then life is simpler.

Do we allow shared objects to be transferred?

There's nothing in the current programmability model that prevents deletion, transfer, or wrapping of shared objects. If you have a shared T, you can use it as a transaction input and do anything you can do with a single-owner T.

However, we can make any or all of these illegal via:

1. Runtime failures. We can abort inside the postprocessing logic adapter if we see a deletion, transfer, or wrap of an object ID that we know was a shared input to the tx.

This isn't the best UX because you might have deleted a shared object in the middle of a tx, then continued executing for some time.

2. New rules on the structure of entrypoints. One idea is to ask entrypoints to take shared T's as input via a Shared<T> wrapper that does not support transfer, deletion, or wrapping. We could then expose functions for some (or none) of these operations if we want to support a subset of them. I like this a bit better because you prevent the bad behavior statically instead of via a dynamic check. But it will be a bit annoying for a programmer to need to dig inside of the Shared<T> every time they want to touch the shared object.

I'm sure there are several other options and am very curious to hear @lxfind's ideas. But perhaps the first thing to align on is which subset of {deletion, transfer, wrap} we want to support for shared objects.

[sblackshear]

One thing I'm wondering about (and this is philosophical/for the future): if we want to support both "modes" of tic tac toe, what is the best way to engineer this?

1. Fully separate modules [current approach]
2. Separate modules that share a common library
3. Single module with some _async functions that can only be called in single-owner mode, some _sync functions that can only be called in shared mode, and (hopefully) a large number of common functions

My instinct is that (2) is probably a cleaner approach than (1) (should lead to less code/test/Move prover spec duplication), but (3) may be a bridge too far. But at some point, we should try them all and see how it shakes out.

[lxfind]

It was somewhat surprising that these two approaches don't share much code at all. The primary reason is that the data storage model changed from storing objects as data into storing primitive data directly. So every function changed because of that. The only things that are still sharable are probably the constants.

[awelc]

It may be worth explaining in TestScenario.move that scenario's object pool contains both "per-address" objects as well as "shared objects" (only the former is implied at this point). The reason I think this could be useful is that it may not super-obvious that after Transfer::share_object any user in any transaction can get this object by calling TestScenario::remove_object.

[awelc]

Are we going to have shared objects by GDC? The comment explaining the status is obviously there but if we are not I wonder if we should still postpone releasing tests for not-yet-fully-supported features to avoid confusion (e.g., people trying this with wallet CLI).

[lxfind]

No we won't have shared objects support in Sui by GDC.
The idea is to be able to put more Move examples that do interesting things (many of them would need shared object support) by GDC though.

[lxfind]

Re: do we allow shared objects to be transferred/deleted

At the moment shared object isn't allowed in Sui (it's only enabled in Move). So it's up to us to decide what we want to allow latter.
Intuitively, I think using a Shared wrapper can be cleaner.
Specifically, when we share an object, what we do is to actually create a new object, with type Shared, which wraps the old object and a non-droppable token in it. This separates the original object and the newly shared object, likely giving us more flexibility on deletion if we ever want to. It also signals a clear intention on which object will be shared in the entry point, which makes Move developers aware of its cost.
To make it easier to use, at entry, the Shared wrapper can be unpacked to the object and the token. The contract can then deal with the object directly in whatever way it wants, but at the end, it must call a native function to put back the object and the token into the Shared wrapper. This ensures that the object cannot disappear otherwise the token will be left alone. Not sure if this would be too confusing though.