refactoring!(state): extend SubmitPayForBlob method

[vgonkivs]

Overview

Resolves #1840

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (feature_branch_blob_module@f5f5efb). Click here to learn what that means.
The diff coverage is n/a.

@@                      Coverage Diff                      @@
##             feature_branch_blob_module    #1963   +/-   ##
=============================================================
  Coverage                              ?   54.55%           
=============================================================
  Files                                 ?      216           
  Lines                                 ?    14021           
  Branches                              ?        0           
=============================================================
  Hits                                  ?     7649           
  Misses                                ?     5553           
  Partials                              ?      819           

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

[distractedm1nd]

I'm worried about adding app types to the API. This means that someone wanting to use our client will now need to also import app. This endpoint was already a bit difficult to use, because users need to construct a namespace.ID, and the fee parameter is a string (math.Int), while gasLim is a uint64. This is just bad UX :/

I am wondering what the best alternative would be. I would handle the complexity inside of node and maybe create our own simple blob type to avoid imports for the user. Do users really need to know about the ShareVersion?

Do you have thoughts on changing the signature to
func SubmitPayForBlobs(ctx context.Context, fee, gasLim uint64, blobs ...blob.Blob) (*state.TxResponse, error)?

[Wondertan]

• Those who use us must import the app whether we rely on the type or not.
• We cannot make state dependant on blob as blob is supposed to depend on it.
  • However, I assumed the modblob, and if we can make the root level blob with blob definition, we might avoid cyclical dependency
  • Yeah, state would depend on blob , and modblob would depend on it. No cyclic dep between modblob and state, so I think we should do it.
  • We can merge this one, then introduce blob with the same blob and update this one or punt this PR until we make blob, up to @vgonkivs

[vgonkivs]

My idea was to merge this one and then update it after introducing the blob struct

[renaynay]

I would actually prefer we hold off on breaking API right now (at least before next release).

[vgonkivs]

Created a feature branch for the Blob Module. So, I can merge everything there and then we can test it

[vgonkivs]

I'm worried about adding app types to the API

I agree here with you. We've discussed with Evan extracting the Blob type to a separate repo, so, we can re-use it. But it's not a high priority rn. I'd suggest leaving app types for now, keeping in mind that they will be changed in the future. (After extracting we can rework basic types)

@distractedm1nd