Creating a proposer client interface

[nisdas]

Addresses #59

• Create a basic interface so that when geth sharding-proposer is entered a basic proposer rpc - client is initiated

[prestonvanloon]

Could you add a pull request description? What are the changes you are making here?

[nisdas]

Added a description above

[terencechain]

Should we add tests and avoid the duplicate code within clients?

[prestonvanloon]

I have a lot of concerns about the patterns we are choosing here. The code is already getting wildly wild and it's probably my fault (I started it).

We have agreed that there are two problems here:

1. There is pretty much no new code, it's the same code as the collator client.
2. There are no tests in this PR.

I think the latter is a product of the former. So let's start with addressing 1 with abstraction. I'd like to see these common methods abstracted into a new interface that both of these clients use. Think about all the things they have in common:

• Endpoint
• Client
• Keystore
• CLI context
• SMC
• Even their constructor methods are very similar

Can you create a "client" interface for sharding that provides all of the above and that the proposer and collator can use?

Read:
https://golang.org/doc/effective_go.html#interfaces_and_types
https://github.com/golang/go/wiki/CodeReviewComments#interfaces

[rauljordan]

I think we should call it shardingClient so that we're different that the ethclient or other packages in the repo.

[terencechain]

I really like this initiative to address our client side abstraction. +1 to shardingClient

[rauljordan]

So the common methods can be receivers for shardingClient, while specific ones can be receivers of CollatorClient and ProposerClient.

[nisdas]

Hey guys, I will be putting up a design proposal soon for refactoring/abstraction of our code so as to provide a solution for the issues that have been raised
Update:
Here is the design proposal
https://docs.google.com/document/d/1__74pTWFpzfLLJ8017XeWQWJfs89YgTGxuefjkFUAaY/edit?usp=sharing