Implicit account actor creation via InitActor method or state manipulation

[anorth]

When a message is sent to a pubkey address that does not yet exist in state, an account actor is implicitly created to receive it. The account actor is allocated an ID and its address mapped through the InitActor's address table.

Should this happen through a message to the InitActor, or by direct manipulation of the InitActor's state? Similarly, should the account actor's state be initialized directly, or by calling it's constructor method? At present the spec performs direct manipulation in the VM (coupling the VM to the InitActor state), Lotus performs direct manipulation from the VM via the state tree (the state tree is coupled to InitActor state), and Go-filecoin sends a message to the InitActor (but semantics are not yet quite right).

Advantages of direct manipulation include:

• avoids overhead and gas cost of two inner message sends
• no awkwardness about how to set up various runtime context values that won't be used anyway
• InitActor.Exec as specced doesn't handle account actors, which need to map the pubkey address not temporary re-org stable address - small change needed

Advantages of sending a message:

• move logic out of the VM into actors (a general design goal)
• reduce coupling between VM and InitActor to only its exported message interface
• doesn't require special-case gas accounting in VM (but charges more gas)

@icorderi @acruikshank @whyrusleeping

[acruikshank]

The only challenge with this is that the direct manipulation needs to cover the following:

1. Retrieve next from in the Init actor's state and increment it in state.
2. Map the id to public key address, and the address to id in the init actor's state.
3. Create a new account actor in the state tree keyed by the id.
4. Initialize the account actor's state with the public key address.

These are precisely the steps performed in Init.Exec with the caveat that the mapped address is a generated address instead of the given public key address. Modifying CreateActor to return the public key address (i.e. the first constructor parameter) when creating account actors avoids duplicating this logic and the infrastructure for state manipulation.

Modulo concerns about gas (which can be addressed) the two approaches should be compatible.