chore: handle PayForBlobNamespaceID in merge

[rootulp]

Closes #1285

Description

1. Handle PayForBlobNamespaceID in merge
2. Extract merge to a new file
3. Add a unit test that uses sample block data

[codecov-commenter]

Codecov Report

Merging #1298 (373657b) into main (abfca15) will increase coverage by 0.08%.
The diff coverage is 82.85%.

❗ Current head 373657b differs from pull request most recent head b3093b7. Consider uploading reports for the commit b3093b7 to get more accurate results

@@            Coverage Diff             @@
##             main    #1298      +/-   ##
==========================================
+ Coverage   49.79%   49.87%   +0.08%     
==========================================
  Files          76       78       +2     
  Lines        4374     4383       +9     
==========================================
+ Hits         2178     2186       +8     
  Misses       2014     2014              
- Partials      182      183       +1     

Impacted Files	Coverage Δ
pkg/shares/reconstruct.go	81.25% <81.25%> (ø)
pkg/shares/parse.go	82.35% <82.35%> (ø)
pkg/shares/share_sequence.go	82.35% <100.00%> (ø)

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

[evan-forbes]

mind pointing out any changes involved in the fix? its a bit difficult to distinguish since we're moving code around.

if we wanted to get a little fancy, we could also modify an existing "fuzzing" integration test that is already generating random block data, to also test reconstruction.

[evan-forbes]

how was this testdata generated? how do we regenerate it?

admittedly, I'm not the biggest fan of using test data because the tests that rely on this could pass indefinitely, even if something in the block changes. imo, we should at least have a function to regenerate it a la https://github.com/celestiaorg/celestia-node/blob/3a1353c0d122e64b991983cf889530e2c7747d10/state/integration_test.go#L120-L147 and even then we'd still want some CI or something to notify us that it changed 😬

if we want to avoid import cycles, then I would prefer that we have those tests in a test package, but this is just a preference and doesn't have to be done in this PR

[rootulp]

how was this testdata generated? how do we regenerate it?

https://github.com/celestiaorg/celestia-node/blob/3a1353c0d122e64b991983cf889530e2c7747d10/state/integration_test.go#L120-L147

how do we regenerate it?

I can add that to celestia-app

[rootulp]

if we wanted to get a little fancy, we could also modify an existing "fuzzing" integration test that is already generating random block data, to also test reconstruction.

I'm concerned the existing "fuzzing" test that tests reconstruction doesn't actually generate pay for blob txs here

[evan-forbes]

I'm concerned the existing "fuzzing" test that tests reconstruction doesn't actually generate pay for blob txs here

whoops, I should have pointed to the test I was thinking of, yeah I think we should test this using blocks that are using more realistic data, like with this test.

https://github.com/celestiaorg/celestia-app/blob/main/app/test/fuzz_abci_test.go

[evan-forbes]

created a follow up for this PR #1322, in which case I think we're clear to merge

[rootulp]

Thanks for creating the follow-up issue. Will merge this as-is because it contains a fix.