[mpool] data race when adding messages

[Stebalien]

We're calling mp.getStateNonce without holding the lock:

lotus/chain/messagepool/messagepool.go

Line 773 in 28d0274

_, _ = mp.getStateNonce(ctx, m.Message.From, tmpCurTs)

This used to be safe, but this method now resolves addresses which can't be done without holding the lock. We should probably just remove this call (mp.getStateNonce) entirely.

We may also be able to get rid of this "warm the cache" logic entirely. We still have a few more instances of GetActorAfter, but I think we can drop those.

[Stebalien]

Nevermind. We still need GetActorAfter if we want to be able to use an account created in the previous tipset. But we can remove the call to mp.getStateNonce (and/or take a lock internally when we resolve the address).

[snissn]

1. delete

   lotus/chain/messagepool/messagepool.go

   Line 773 in 28d0274

   _, _ = mp.getStateNonce(ctx, m.Message.From, tmpCurTs)

2. delete

   lotus/chain/messagepool/messagepool.go

   Line 784 in 28d0274

   _, _ = mp.getStateNonce(ctx, m.Message.From, tmpCurTs)

3. instead of call getActorAfter, call getActorBefore then if it does not exist call getActorAfter -- all we need is actor code CID or sending address, not nonce

[Stebalien]

So, we have a couple of options. Either:

1. Call GetActorBefore, then GetActorAfter if it turns out that the actor doesn't exist yet.
2. Drop support for sending messages from an account immediately after creating it. Honestly... this seems reasonable.

For 2, we'd just replace

lotus/chain/messagepool/messagepool.go

Line 877 in 28d0274

senderAct, err := mp.api.GetActorAfter(m.Message.From, curTs)

with GetActorBefore and remove all the logic around "warming the cache" in general.

[snissn]

Sounds good! I opened a PR for 2): #10758

[Stebalien]

Turns out this isn't actually an issue.