Refactor Gravity nonce implementation

[byte-bandit]

Problem description

The original gravity code assumes a 1:1 relation between the local chain and the remote chain. Paloma, however, supports tokens across n chains, leaving us with a 1:n relationship.

This causes headaches across the following areas:

• Paloma only keeps track of the latest observed nonce and latest observed block height for one chain, instead of n
• Paloma also keeps all attestations in one store, instead of one store per remote chain
• Attestation assumes that the observed nonces will always increase exactly by 1, which they won't if they're shared between different chains
• Probably more that I don't see right now

This is the price we pay for not having written the module ourselves and just copied it over. To support our use case, I think we'd need one keeper per remote chain, but I don't think that's feasible with the Cosmos architecture. So instead, we need to hack what we have to support the n chain constraint.

Action plan

• Refactor Paloma gravity keeper to respect the contextual reference chain ID
  • Last observed BH by chain
  • Last observed nonce by chain
  • Attestations by chain
  • Last nonce by validator and chain
• Update Compass, event_id actually seems to be the gravity_nonce, but it's used throughout the board. Remove usages across other, non-gravity related functions and revert the last PR that added the second nonce. Also rename it to be more clear on intentions.
• Update Paloma to work with the new compass, both payload & generative logic. We will keep a separate event_id for better traceability.

[taariq]

@byte-bandit this is fixed with palomachain#1174 yes?

[byte-bandit]

Not completely. The last changes for this I"m still working on.