feat(rpc): Transaction proxy for staking tx types

[distractedm1nd]

Resolves #946

• Implement each transaction type proxy inside of core_access.go
• expose these methods via higher level Accessor interface and have Service proxy to the accessor's impl of them
• expose via RPC
• Testing

[codecov-commenter]

Codecov Report

Merging #984 (8d584fd) into main (2cc8077) will decrease coverage by 1.40%.
The diff coverage is 2.33%.

@@            Coverage Diff             @@
##             main     #984      +/-   ##
==========================================
- Coverage   58.53%   57.13%   -1.41%     
==========================================
  Files         132      132              
  Lines        7947     8161     +214     
==========================================
+ Hits         4652     4663      +11     
- Misses       2818     3023     +205     
+ Partials      477      475       -2     

Impacted Files	Coverage Δ
service/rpc/state.go	0.00% <0.00%> (ø)
service/state/core_access.go	12.06% <0.00%> (-6.27%)	⬇️
service/state/service.go	35.48% <0.00%> (-12.35%)	⬇️
cmd/celestia/main.go	62.50% <100.00%> (+1.63%)	⬆️
service/rpc/endpoints.go	100.00% <100.00%> (ø)
header/core/listener.go	52.83% <0.00%> (-5.67%)	⬇️
ipld/retriever.go	93.58% <0.00%> (+1.60%)	⬆️
ipld/nmt_adder.go	92.00% <0.00%> (+24.00%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[distractedm1nd]

Biggest open question now is the best way to test these!

[renaynay]

Nice!

[renaynay]

@distractedm1nd did you manually test these endpoints by chance?

[distractedm1nd]

I did not, I need to set up a better mock environment/local dev network, which I have been putting off... How difficult will it be to write unit tests for these, since we are actually depending on app here? Can we mock it easily?

[renaynay]

We unfortunately cannot write unit tests for app-related state interaction right now because of how difficult it is to mock away the app.

[distractedm1nd]

All new endpoints have been tested now and work as expected

[adlerjohn]

No comments on the code itself. One thing that I'm not a fan of is that this seems to require/assume that there's a wallet, which has nothing to do with a Celestia Node. Is there some plan to separate the wallet from the node?

[renaynay]

@adlerjohn we already have basic "key management" via the cosmos-sdk key utility (see cel-key). The idea here is that it's a very small surface / very small implementation necessary to proxy a basic tx type so that a user who holds funds on the celestia network does not need to spin up another node type or access some other RPC separately in order to submit these kinds of txs.

Does that make sense?

[Wondertan]

@adlerjohn +1 on what Rene said. Also note that there is no other gateway in our network to request state in trust minimised way besides the node. Here, we just add more state transactions/writes capabilities and further, reads for this state modules will come as well.

I am also a big fan of having wallet capabilities on the Node. We already do that to manage balances and further the will be support for addresses/account management.

[Wondertan]

LGTM