Implement optimal message selection

[creativcoder]

Summary of changes
Changes introduced in this pull request:

• Closes Implement a correct chain abstraction for optimal message selection #1054 and Implement optimal message selection #1023

Reference issue to close (if applicable)

Closes

Other information and links

[cryptoquick]

slotmap looks really neat! However, I'm afraid I'm not able to provide review without further context.

[ec2]

LGTM aside from the clippy issues and nightly build check.

[cryptoquick]

Thank you for the HackMD primer you made on Optimal Message Selection. It was very useful to understand the context of this PR.

I don't have specific comments on this PR, but I would like to ask a few general questions.

Do you have an idea of how many messages will be in the SlotMap each time?

Because the SlotMap is frequently cleared, I wonder if we shouldn't use the HopSlotMap, with a predefined (rough estimate) of capacity, using with_capacity_and_key, and then using the clear method to explicitly clear its contents.

Also, I noticed you removed the comment "TODO: Implement guess gas". Is that implemented now, say, via chain message? If so, are we checking against the new MIN_GAS constant anywhere the new, dynamic min_gas value should be used instead?

Finally, do you have any test cases? How have you observed that this new message selection algorithm works?

[creativcoder]

Thank you for the HackMD primer you made on Optimal Message Selection. It was very useful to understand the context of this PR.

I don't have specific comments on this PR, but I would like to ask a few general questions.

Do you have an idea of how many messages will be in the SlotMap each time?

Glad you found it helpful Hunter. Um, @ec2 might have a better answer on that. When I ran the tests for optimal selection (3 of them) I get about 1437 messages picked out of the selection method. It will usually be variable though.

Because the SlotMap is frequently cleared, I wonder if we shouldn't use the HopSlotMap, with a predefined (rough estimate) of capacity, using with_capacity_and_key, and then using the clear method to explicitly clear its contents.

We don't delete anything from the map anytime during the algorithm, it gets de-allocated at end of the method. We just remove, invalidate pointers to them.

Also, I noticed you removed the comment "TODO: Implement guess gas". Is that implemented now, say, via chain message? If so, are we checking against the new MIN_GAS constant anywhere the new, dynamic min_gas value should be used instead?

So gas_guess is actually referring to a module from lotus impl. As of now we only use two constants from it and we don't have the rest of entities being used anywhere in forest. Yeah, it's better to put the TODO comment back, actually at the top where MIN_GAS constant is defined.

Finally, do you have any test cases? How have you observed that this new message selection algorithm works?

Yes, selection.rs contains 3 test cases for optimal selection. Starts here: selection.rs They are direct ports of lotus' selection_test.go

[cryptoquick]

I feel comfortable with those answers! Fantastic work!

I think we should get this in before we merge #1033 due to our changes to how the keystore is created (Memory, Persistent, Encrypted). We'll handle those changes when we update our branch.

[cryptoquick]

Also, don't forget to make the linter happy!

https://app.circleci.com/pipelines/github/ChainSafe/forest/4132/workflows/6168d5f9-bf19-40ad-a466-55f4d693c3c4/jobs/15493/parallel-runs/0/steps/0-111