feat: separate simple client into its own module

This will make it easier to import it into other projects without importing all of the other dependencies of our root go.mod.
We will first merge this PR with a replace directive in the main go.mod, then release v0.1.0 of the new client module, and then
make a new PR to use that version in the main go.mod file.

client/go.mod

@@ -0,0 +1,10 @@
+// We use a separate module for the client to allow dependencies to import it without importing all of proxy's main module's dependencies.
+// This follows the recommendation in: https://go.dev/wiki/Modules#should-i-have-multiple-modules-in-a-single-repository
+//
+// Two example scenarios where it can make sense to have more than one go.mod in a repository:
+// 1. [omitted]
+// 2. if you have a repository with a complex set of dependencies, but you have a client API with a smaller set of dependencies.
+//    In some cases, it might make sense to have an api or clientapi or similar directory with its own go.mod, or to separate out that clientapi into its own repository.
+module github.com/Layr-Labs/eigenda-proxy/client
+
+go 1.21.0

go.mod

@@ -6,6 +6,7 @@ toolchain go1.22.7
 
 require (
 	github.com/Layr-Labs/eigenda v0.8.5-rc.0.0.20241101212705-fa8776ae648c
+	github.com/Layr-Labs/eigenda-proxy/client v0.0.0-00010101000000-000000000000
 	github.com/avast/retry-go/v4 v4.6.0
 	github.com/consensys/gnark-crypto v0.12.1
 	github.com/ethereum-optimism/optimism v1.9.5
@@ -24,6 +25,9 @@ require (
 	google.golang.org/grpc v1.64.1
 )
 
+// TODO: Remove this after we have published v0.1.0 of the new client module.
+replace github.com/Layr-Labs/eigenda-proxy/client => ./client/
+
 require (
 	dario.cat/mergo v1.0.0 // indirect
 	github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1 // indirect