Add EigenDA client using handshake based authentication

[teddyknox]

Why are these changes needed?

To provide a client for accessing EigenDA with the following features:

1. BN254 31-byte encoding (dispersal and retrieval)
2. Length prefix encoding to return exact blob length that was dispersed (dispersal and retrieval)
3. IFFT encoding to enable location specific point opening for fraud/validity proofs. (dispersal and retrieval)
4. Automatically waiting for finalization (abstracting over DisperseBlob() and GetBlobStatus()).
5. Implement ECDSA signature based authentication.

This client will unify logic across many integrations and make EigenDA integrations easier to maintain.

This change also unifies the api/ package into the root module, which can be done because the original reason for separating api into its own module no longer applies; we have upgraded certain dependencies within the root module that were conflicting with Optimism's set of dependencies before.

My testing strategy here has been based on testnet integration tests, since otherwise testing this client would require either mocking out the disperser, spinning up an entire inabox environment, or some middle ground between the two. For now, given time constraints, it is fine to verify that the client works against testnet.

Checks

• I've made sure the lint is passing in this PR.
• 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.
• Testing Strategy
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[mooselumph]

What is the intended relationship between this client and the client in the clients folder? This is creating a lot of duplication. Moreover, the client there is integrated into several unit tests throughout the codebase.

This change also unifies the api/ package into the root module, which can be done because the original reason for separating api into its own module no longer applies; we have upgraded certain dependencies within the root module that were conflicting with Optimism's set of dependencies before.

Do we anticipate this remaining to be the case?

If we are using the same module, then why should this code be contained in the api folder instead of the prexisting clients folder?

[epociask]

just some small comments - otherwise looks really good

[ian-shim]

This kind of client implementation makes sense, and code lgtm. But I feel like it should belong on the integrator's codebase.
Is this client tailored for a specific integration or all integrations?
If it's tailored for a specific integration, it should belong in the integrator's codebase utilizing the generic disperser client.
If your judgement is that all integrations will use this client, we should update the existing client.

What do you think?

[teddyknox]

Thanks for all the feedback on this PR. I wasn't aware of the existing EigenDA client in the clients/ directory as pointed out by @mooselumph but I'm open to combining them. They seem to be operating on two different levels, where this one is higher-level and handles encoding and status polling, and the existing client seems lower-level, and offering polish over the GRPC endpoints and handshake-based authentication.

Since the existing client is being used for traffic generation and integration tests which depend on its lower level semantics, it doesn't seem viable to fold that client into this one.

Conversely, it does seem possible to factor out aspects of this client which could be handled by the lower-level client, but would require some duplication of supporting code, e.g. separate config objects etc. This is the path I will take in pending follow ups to this PR.

Based on @epociask's requests I think it does make sense to mock out the apiserver for the purpose of testing failure cases of this client, that work is also pending. For now though I've updated the branch with another draft of refactors that respond to the comments above.

[teddyknox]

Ok I've updated this client to depend on the existing low level EigenDA client. The only thing I'd change about the low level client at this point is that the low level client reconnects with the server with every request. This seems like overkill, since GRPC connections are virtual and can abstract over whether there is a real TCP connection going at any point in time.

[teddyknox]

In my latest push I've further updated this PR to add tests.

[ian-shim]

lgtm, one comment on validation

[ian-shim]

It would be better to rename the method name to make it clear to the caller that this method modifies the content of the receiver (or return a new config instead of modifying the receiver in place).