Update Cosmos Network Alerter to check for proposal votes

[Cherrett]

This issues tackles two aspects of the Cosmos Network Monitoring/Alerting:

User Story

As a node operator, I would like to know whether I voted on a given proposal.

Technical Story

As the Cosmos Network Alerter, I do not require the Cosmos Network Alerting Factory to keep track of the active proposals since this is being done using the proposals obtained in the previous monitoring round.

Description

For cosmos network alerting, currently, we are only checking for new/ended proposals. This needs to be updated to also check if a validator has voted in voting-period proposals. This can be done using the /cosmos/gov/v1beta1/proposals/PROPOSAL_ID/votes/VOTER_ADDRESS cosmos rest endpoint. This is for the new cosmos rest version so we must check the alternative, if any, for the old cosmos rest versions which we currently cater for.

Currently, the Cosmos Network Alerter is checking the proposals stored in the Cosmos Network Alerting Factory before sending proposal alerts. This can be removed since this is already being done within the alerter itself by checking the previous and current proposals obtained from the Cosmos Network Data Transformer.

Requirements

• Update Cosmos Network Monitor to check voting status of validator addresses for proposals in voting-period.
• Update Cosmos Network Data Transform to cater for new voting data if need be.
• Update cosmos network proposal alerts to include voting status details.
• Update Cosmos Network Alerter to use proposal voting data as required.
• Update Cosmos Network Alerter to remove the logic of checking with the factory before sending proposal alerts.
• Update Cosmos Network Alerting Factory to no longer track proposals.
• Update tests for the components above accordingly.
• Make sure that proposal alerts + votes are being raised properly.

Blocked by

N/A

Acceptance criteria

Scenario: The CosmosNetworkAlerter is started Given: PANIC started When: Checking the log files inside the alerter/logs/alerters and the docker-compose console Then: You can see correct startup

Scenario: The CosmosNetworkAlerter has no error logs (apart from the data sending part due to no consumer) Given: PANIC is running When: Checking the log files inside the alerter/logs/alerters Then: You can see no error logs

Scenario: The CosmosNetworkAlerter is receiving transformed data from the CosmosNetworkDataTransformer Given: PANIC is running in Debug mode (by putting LOGGING_LEVEL=INFO inside the .env file and restarting panic) When: Checking the log files inside the alerter/logs/alerters Then: You can see the correct data being received.

Scenario: The CosmosNetworkAlerter is raising alerts correctly Given: PANIC is running in Debug mode (by putting LOGGING_LEVEL=INFO inside the .env file and restarting panic) When: Checking the log files inside the alerter/logs/alerters Then: You can see the correct proposal alerts with the correct votes.

Scenario: The Telegram Commands Handler and Slack Commands Handler do not show any issues on /status and /panicstatus commands respectively. Given: PANIC is running with a Slack Commands Handler and Telegram Commands Handler When: Typing /status and /panicstatus Then: You can see that PANIC is running smoothly

[Cherrett]

Moreover, similarly to how referendums will be handled in the Substrate Alerter, we can have a single unique key which caters both new/concluded proposals.

[Cherrett]

In addition to this, we can potentially check a proposal's type/module to differentiate upgrade-related proposals. If such proposals pass, we may alert in a different way to remind the user to upgrade/update based on the proposal's information.

[Cherrett]

For the above, I think we might need to check for the ClientUpdate type if possible; example