Extract blob key computation logic into static function

[litt3]

Why are these changes needed?

• It isn't possible to construct a BlobHeader with the data available on chain, since we don't have access to the payment metadata
• The changes in this PR allow access to the BlobKey computation logic, without using a BlobHeader middle man
• This functionality will be needed to support client V2, since validator nodes will have an EigenDACertificate, which doesn't contain payment metadata

Checks

• I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
• I've checked the new test coverage and the coverage percentage didn't drop.
• Testing Strategy
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[cody-littley]

fairly straight forward change, LGTM

[samlaf]

Idea LGTM, but not a big fan of having a seemingly function that takes a bunch of arguments whose relationship is unclear. I mentioned this already in arch's onchain renaming PR but I would prefer if we had a struct with a name for "DACertWithHashedPaymentHeader". Then this function could be a method on that struct.

Would make the hashing structure way more clear imo:

[litt3]

Idea LGTM, but not a big fan of having a seemingly function that takes a bunch of arguments whose relationship is unclear. I mentioned this already in arch's onchain renaming PR but I would prefer if we had a struct with a name for "DACertWithHashedPaymentHeader". Then this function could be a method on that struct.

If we're opening the conversation for more fundamental changes, my question is:
Why do we include the payment metadata directly in any form of a BlobHeader? Why don't we just always put the hash in there, and send the payment metadata along with our dispersal request, as a separate object?

It seems over complicated to define multiple versions of the same object with subtle differences.

[litt3]

@samlaf As suggested by @mooselumph in slack, let's go with this simple static function for now. The other options will require a longer discussion, and much more code changes to complete

[samlaf]

SGTM. let's roll with this for now