chore(api/clients/v2): Reference prover via interface vs raw struct

[ethenotethan]

Why are these changes needed?

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 :(

[samlaf]

Why is this change needed? The prover is passed to the NewDisperserClietn constructor, which works fine with a nil pointer. In fact, by passing an interface in, I think you break the actual logic inside the DisperserClient (the nil check will evaluate to false) even when kzgConfig == nil

EDIT: I was wrong, will update with approval

[samlaf]

I was wrong. This fix is indeed a fix. The problem is in the DisperserClient. It checks for if c.prover == nil which checks if the interface is nil.
But here we were passing a nil pointer, which in the constructor was being wrapped in a NON-NIL interface that pointed to the nil pointer struct. So the if c.prover == nil was not working.

We can merge this as a fix, but @litt3 I would prefer if we actually fix the DisperserClient. An ugly solution is to check in the constructor if prover is an interface that points to a nil struct and set the prover to be nil in those cases. A better solution is what I had asked for originally to instead not rely on c.prover == nil and use a proper NoProver implementation of the interface. What was the reason for this not working again?

One thing we could do in the meantime is just to add

if opts.Prover != nil && reflect.ValueOf(opts.Prover).IsNil() {
            prover = nil  // explicitly set to nil interface
        }

to the constructor to allow passing a nil struct instead of a nil interface.

[ethenotethan]

+1 to using Noop prover

[litt3]

What was the reason for this not working again?

@samlaf It's not that the solution won't work. The DisperserClient needs to be fixed, it just hasn't been undertaken yet

I want to still do a deep dive exploration of alternate strategies, but I agree the Noop path sounds like the likely solution