Batched delegations

[sampocs]

Context

In order to support validator sets of 100+, we have to batch delegations so that we don't exceed the gas limit. This PR handles the changes in the delegation submission. The callback will be in a separate PR.

Note to reviewer: I'd recommend reviewing commit by commit

Brief Changelog

• Added DelegationTxsInProgress field to deposit record for retry protection - it's incremented when delegation is submitted and will be decremented in the callback
• Split DelegateOnHost into two functions: GetDelegationICAMessages and BatchSubmitDelegationICAs. The former builds up all the batches across validators, and the latter submits the ICAs in batches
• Removed the max cap on deposit records - it's unnecessary
• Added unit tests

[ethan-stride]

LGTM very thorough unit tests

This is a summary of the ways in which this one was slightly different from the undelegate batch logic just to confirm my understanding. Deposit records are more temporary than unbonding records because depositing can happen instantly and as soon as it finished we can discard the record, but unbonding needs to know how to accurately claim 21 days+ later. So there is no need for a retry specific queue -- if it fails just put it back into the original queue of ones needing to be handled because all the matters is has it been processed yet or not and once the full amount on the record has been deposited delete the record.

In undelegate batching, you computed the total amount needed to come from a validator so that only one message had to go to each validator affected. But here for deposit the messages are built based on an incoming param of the specific depositRecord. Any deposit it likely to cause msgs to go out to almost all of the validators on its hostZone because of the proportional weighted split strategy. Seems like we actually should aggregate before batching so msgs going to the same validator would be combined. Two depositRecords from the same hostZone seems like a semi common case we can easily reduce the number of ICAs by aggregating per validator, and then chopping the msgs into batches. If you do this, you would need to change the split delegation structure to have different amounts per depositRecord to update the deposit records correctly but it would still be one splitDelegation per msg.

Overall I think it makes sense and is sound as is but we might be able to save many ICAs based on the batching strategy

[sampocs]

@ethan-stride re: combining deposit records

I think during the design phase we landed on sending messages per one record for simplicity (.e.g. no loops) - I don't think submitting an extra ICA to each validator is too concerning.

Long term, what I think we should really do is combine the two deposit records into 1 (e.g. instead of creating a new record from rewards, we just add the amount to the existing record). And then we can keep the code as is, but it essentially accomplishes the same goal your after. But I think this is outta scope at this point

[riley-stride]

Lgtm

[shellvish]

Looks great, thanks a ton for doing this!