Implement relay url provider

[litt3]

Why are these changes needed?

• This PR changes how the relay client is interacted with: rather than constructing a new relay client every time there are updates, the relay client now is able to create new connections on the fly, as they are added
• This PR is needed to support blazar clients, which currently don't have a way to receive relay URL updates
• In addition to implications for the blazar clients, this changeset has implications for DA validator nodes, which should be considered when reviewing this PR

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

[ian-shim]

DefaultRelayUrlProvider sounds like there should be other relay URL provider implementations. Maybe we can just call it relayURLProvider unexported?
NewRelayURLProvider can return the struct pointer as RelayURLProvider type.

[ian-shim]

nit: not sure how useful this abstraction is. It simply wraps the eth client to fetch relay info from chain. Could we just use EthClient straight from the relay client?

[litt3]

nit: not sure how useful this abstraction is

There are two reasons I thought it makes sense to create this abstraction:

1. it allows for a test implementation of the functionality
2. In the (near?) future, the relay registry will need to be updated with functionality to remove and update entries. At that time, there will be much more logic, and making this split now means that future changes to the RelayURLProvider won't require changes to the relay client

[litt3]

DefaultRelayUrlProvider sounds like there should be other relay URL provider implementations

Did you notice that there is a TestRelayUrlProvider implementation? That was the reason I chose the Default prefix, curious if that affects your opinion at all

[ian-shim]

I thought you could have easily mocked this class, but I don't think that's true because you're passing in the client in the binding to generate the caller.
I'd still prefer calling this class something like relayURLProvider though. Yes, TestRelayUrlProvider is an alternative implementation of the interface but it's only intended for testing. In fact, I'd put TestRelayUrlProvider and the tests in a different package (i.e. relay_test) so that structs intended for testing aren't exported from the main package.

[litt3]

I renamed to relayURLProvider, and moved the test implementation into the test package

[ian-shim]

What happens if this fails? relayInitializationStatus for this key has been set to true and grpcRelayClients.Load will continue failing, right?

[litt3]

That's how the current implementation behaves, yes.

Do you think it makes more sense to rework the method, such that a failed fetch doesn't result in the initialization flag being set to true?

Callers would therefore infinitely retry the initialization (lazily), with the rate of retries being limited by the timeout configured on the context.

[litt3]

Or, alternatively, I could implement more specific retry logic to limit the rate.

[ian-shim]

What if we just set relayInitializationStatus to true at the end of the method only when it's successful?
If any of these rpc calls fail, the relay client just returns error, but any subsequent calls would retry.

[litt3]

Sounds good- done

[ian-shim]

nit: filename

[litt3]

Fixed