feat: chainstore: optimize BlockMsgsForTipset

[arajasek]

Related Issues

@raulk observed some slowness due to the repeated resolution of senders in this method.

It's necessary to resolve senders if AND ONLY IF we have a message sent by an ID address. If we don't (which we almost never do), we can just use robust addresses.

Proposed Changes

Use robust addresses, instead of ID addresses, to check nonces when selecting BlockMsgsForTipset, BUT check if we have any messages sent from ID addresses.

If we do find any messages sent from ID addresses, switch to using ID addresses for the resolution.

Speeds up BlockMsgsForTipset from ~25ms on average to ~5 ms on average (on my desktop).

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Stebalien]

This assumes that accounts will only ever have an f0 plus an f1/f3/f4 address, never more. That's currently true and likely to continue to be true? Maybe? With account abstraction, that may go away.

But I guess this should be OK for now.