pre_init messages

[agouin]

Adds tracking for initial messages in the path processor. Previously, there was no retry handling for the initial messages:

• MsgConnectionOpenInit in the connection handshake
• MsgChannelOpenInit in the channel handshake
• MsgTransfer for relayer initiated packet transfers (not part of standard operation)

The path processor would send these desired initial messages upon startup but they were not included in path processor correlation.

Now, this initial state before there is anything on-chain is tracked with a unique key preInitKey. This allows the path processor correlation to take effect, so that any failures for initial messages (such as account sequence errors) will be retried.

Additionally, this modifies the "get unrelayed" methods for connection handshakes, channel handshakes, and packet flows so that only the immediate prior step is required in the cache to proceed to the next step. Previously, in order to determine that a MsgConnectionOpenConfirm (for example) should be relayed from the source chain to the destination, the path processor would need the following to be cached:

• connection_open_init from the source
• connection_open_try from the destination
• connection_open_ack from the source

Now, the caches are kept slimmer, and the only information required to make the same determination is:

• connection_open_ack from the source

The caches are now pruned along the way throughout the handshake, keeping only minimal information. The same logic now applies for channel handshakes and packet flows.

The main driver for this is the intermittent failures in the packet forward test due to multiple paths being linked at the same time from separate relayer instances, so they should to be able to retry for account sequence errors.

[jtieri]

lgtm, this is a great addition and the clean up is much more readable (specifically path_processor_internal)