feat(executor): added MsgUpsertSequencer consensus message

[keruch]

PR Standards

ADR link https://www.notion.so/dymension/ADR-x-Sequencer-Reward-Address-On-Rollapp-da84af6888c141d0a4c1a8df256a5025
Closes dymensionxyz/dymension#1248

---

For Author:

• Targeted PR against correct branch
• included the correct type prefix in the PR title
• Linked to Github issue with discussion and accepted design
• Targets only one github issue
• Wrote unit and integration tests
• All CI checks have passed
• Added relevant godoc comments

---

For Reviewer:

• confirmed the correct type prefix in the PR title
• Reviewers assigned
• confirmed all author checklist items have been addressed

---

After reviewer approval:

• In case targets main branch, PR should be squashed and merged.
• In case PR targets a release branch, PR should be rebased.

[faultytolly]

I think there should be a way to test it

[zale144]

For the initial RewardAddress, the settlementAddr is used. Do we need to include both in the consensus message? Is there a scenario where this message can carry two distinct addresses, one Operator and the other Reward address?
Do I understand this correctly, to have a reward address different from the settlement addr, the custom reward address can be set on the rdk manually, in which case the RewardAddrBytes will not override it?
I realize keeping the reward address in the Hub was decided against, but if we recognize the Hub's x/sequencer record to be the source of truth for the sequencer, then we could maybe consider that besides the settlement address, the (custom) reward address could also originate from the Hub's sequencer record. What do you think?

[keruch]

Regarding your last point. Yes, you are right. That's what we finally decided to do with Omri. We'll enrich the rotation_started event with all the information needed for the sequencer, ie RewardAddr and WhitelistedRelayers so far. And the hub will be the source of truth.

Do we need to include both in the consensus message?

Good point, probably we don't. But as i said above, this will be change anyway soon.

Do I understand this correctly, to have a reward address different from the settlement addr, the custom reward address can be set on the rdk manually, in which case the RewardAddrBytes will not override it?

Currently, RewardAddrBytes overwrites the manually set value. Again, this will change once we accept that the Hub is the source of truce.

[keruch]

I think there should be a way to test it

@faultytolly Existing tests already cover the code I added. I even adjusted some existing scenarios to make tests green, you can see the diff.

[keruch]

The build fails while the RDK PR dymensionxyz/dymension-rdk#568 is not merged.