feat: add message to withdraw emission rewards

[kingpinXD]

Description

• Add a message to enable observers to collect emission rewards

Closes: #1653

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Include instructions and any relevant details so others can reproduce.

• Tested CCTX in localnet
• Tested in development environment
• Go unit tests
• Go integration tests
• Tested via GitHub Actions

Checklist:

• I have added unit tests that prove my fix feature works

[codecov]

Codecov Report

Attention: Patch coverage is 87.87879% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 38.70%. Comparing base (cfd27a7) to head (d2e3fd9).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1811      +/-   ##
===========================================
+ Coverage    38.03%   38.70%   +0.66%     
===========================================
  Files          205      208       +3     
  Lines        12524    12623      +99     
===========================================
+ Hits          4764     4886     +122     
+ Misses        7372     7349      -23     
  Partials       388      388              

Files	Coverage Δ
x/emissions/abci.go	85.58% <100.00%> (+3.36%)	⬆️
.../emissions/keeper/msg_server_withdraw_emissions.go	100.00% <100.00%> (ø)
x/emissions/keeper/withdraw_emissions.go	100.00% <100.00%> (ø)
x/emissions/keeper/withdrawable_emissions.go	100.00% <100.00%> (+100.00%)	⬆️
x/emissions/types/message_withdraw_emissions.go	42.85% <42.85%> (ø)

[lumtis]

I'm not sure to understand.
Why creating a withdraw object in the message and processing it in the endblocker, instead of directly processing it in the message?
What does the WithdrawEmission object brings on top of WithdrawableEmission?

[lumtis]

Why using a defer here? It seems we never return an error in the function body

[kingpinXD]

I used it just for code readability.

[kingpinXD]

I'm not sure to understand. Why creating a withdraw object in the message and processing it in the endblocker, instead of directly processing it in the message? What does the WithdrawEmission object brings on top of WithdrawableEmission?

This is to prevent more than one emission withdraw in the same block. Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own , Using the endblock and processing all withdraws in the block at once makes the logic a bit safer
I don't think it adds much of an overhead on top of a regular tx .

[lumtis]

I'm not sure to understand. Why creating a withdraw object in the message and processing it in the endblocker, instead of directly processing it in the message? What does the WithdrawEmission object brings on top of WithdrawableEmission?

This is to prevent more than one emission withdraw in the same block. Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own , Using the endblock and processing all withdraws in the block at once makes the logic a bit safer I don't think it adds much of an overhead on top of a regular tx .

I don't get it.

We have a WithdrawableEmissions object, already in the store, containing the amount an address can withdraw.
We're implementing a MsgWithdrawEmission that creates a WithdrawEmissions containing the exact same fields as above.
The end blocker iterates these WithdrawEmissions, send funds to user, delete WithdrawEmissions and subtract WithdrawableEmissions from value in WithdrawEmissions

Why not directly having MsgWithdrawEmission that decrease WithdrawableEmissions and send funds to user?

This is to prevent more than one emission withdraw in the same block.

Why is it a problem if we verify that the withdrawn amount is below withdrawable amount?

Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own

How does using a intermediate end blocker add more protection for this?

[kingpinXD]

Closing pr for now to make changes mentioned above cc @lumtis