Make Manager and Configuration an interface to ease testing

[s111]

This might or might not be a good idea, but I was thinking about having Manager and Configuration be interfaces. This should be easy enough to generate but we will end up having to change the implementing structs names, which should be fine. This might ease testing when your code is coupled to the network, i.e., Gorums, as you can mock out the Manager and Configurations.

I guess my main point with doing this was that we could mock out the network layer and easier create deterministic tests with, e.g., specific interleaving of messages, network delays and patriotions. This might end up being a rather large task. Just making the Manager and Configuration be interfaces might not be that big of a deal though.

[meling]

Finally started to look into this. Sounds reasonable to me. I think it would be very useful if we can make the Manager and Configuration interfaces be part of the public API of Gorums, so that these interfaces need not be generated. This can also allow us to create helper functions, e.g. test helpers, for setting up Gorums.

[meling]

Here is a proposed interface for Configuration.

// Configuration represents a static set of nodes on which quorum remote
// procedure calls may be invoked.
type Configuration interface {
	Nodes() []*Node
	Size() int
	NewQuorumSpec() QuorumSpec
}

The NewConfiguration method should return the generated struct (not the interface), since then the interface does not need to contain the RPCs generated from the proto file.

The main issue is how can we access the QuorumSpec; we need generics.

[meling]

When reviewing a PR a while back I noticed that we don't actually use the Nodes() method, nor the NodeIDs() method from within Gorums itself. The question is whether or not one or both of these methods will be useful as part of this interface.