Example: increment-only counter

[peterbourgon]

An increment-only counter shared among peers, as a strawman to test and improve upon the user-facing API.

Suggested action items from this experiment:

• Rename mesh.Config to mesh.RouterConfig.
• Modify mesh.NewRouter to place mesh.RouterConfig last, and ensure sensible defaults if fields aren't specified.
• Create simplified mesh.NewSimpleRouter constructor, with fewer options.
• As a user, I have no way of knowing what type of string I should pass to PeerNameFrom{String,UserInput}, except a priori. So, I propose to remove non-MAC-based PeerName, and amend MAC PeerName documentation to make it clear it's not strictly necessary to use a MAC address.
• Move InitializeConnections to the Router object directly, so we can eliminate connectionMaker from the exported API
• In the router, port should be a string, just as everywhere else in the standard library.
• Improve documentation and provide examples of what is an Overlay and why I should care. (Will investigate this in the next example.)
• mesh should use a passed logger rather than the global logger

[rade]

Remove non-MAC-based PeerName, and amend MAC PeerName documentation to make it clear it's not strictly necessary to use a MAC address

But if MAC PeerName is the only one supported, then how would one "not use a MAC address"?

[peterbourgon]

The problem is that users have a choice that's conditional on a build flag, which no one will use. Perhaps we can strictly type PeerName string and provide multiple constructors,

• func NewHardwareAddrPeerName(hwAddr string) PeerName
• func NewHexPeerName(hex string) PeerName
• func NewHashablePeerName(userInput string) PeerName
• func NewBytesPeerName(buf []byte) PeerName

[rade]

That won't work. The choice of peer name representation is a build time flag for a reason: it affects the protocol and therefore has to be the same on all weave peers.