Introduce hashicorp/go-metrics compatibility (#760)

* Introduce hashicorp/go-metrics compatibility

Compatability is attained with build tags

Using tag armonmetrics or no tag at all will result in the library utilizing github.com/armon/go-metrics for metrics emission (like it has historically done)

Using tag hashicorpmetrics will result in the library utilizing the updated github.com/hashicorp/go-metrics for metrics emission.

* Update README.md

* Bump versions of memberlist and go-metrics to pull in go-metrics compat package

updating to memberlist v0.5.0 (#664)

* updating to memberlist v0.5.0

* running gomod tidy

Add metrics labels (#658)

* Add labels to metrics
* upgrade memberlist to 0.4.0

Co-authored-by: R.B. Boyer <[email protected]>

Add label for ping msg; config memberlist metrics label (#654)

- Add lable for ping msg
- config metrics for memberlist

fix an out of bound access in `keyListResponseWithCorrectSize` (#649)

* fix an out of bound access in `keyListResponseWithCorrectSize` and add a relevant test

* add extra tests

finish the leave process if broadcasting leave timeout (#640)

* finish the leave process if broadcasting leave timeout

* Log broadcast timeout as WARN and finish the Leave process.

* increase timeout

update memberlist to 0.3.0 (#639)

Merge pull request #614 from hashicorp/feature/per-node-reconnect-tim…

…eout

Avoid issue where two unique leave events for the same node could lea…

…d to infinite rebroadcast storms (#606)

Fixes this scenario:

When two leave events for the same node (with different ltimes) are
received by two or more additional nodes without any intermediate state
transitions it will lead to them setting up an infinite gossip echo
chamber rebroadcasting the original node's leave.

When in this situation the only way to recover would be to either:

- Bring the node back so it can send out a fresh "alive" message.

- Use force-leave prune to purge the node's existence from the cluster.

There are two known ways to arrive in this situation:

1. Have a node leave the cluster and then from a different node initiate
   a force-leave. This is the easiest way to reproduce.

2. Have a node leave, rejoin, and leave again in quick succession. This
   requires winning a lot of races in just the right way to have gossip
   from the first leave still rebroadcasting naturally WHILE the second
   round of leaves is rebroadcasting AND to have those rounds of gossip
   arrive at the target nodes before they see the rebroadcast of the
   intervening REJOIN.

The fix is pretty simple. When we witness a node leave event, before we
rebroadcast we need to update the lamport time associated with that node
so that the ltime check will cause the same event to be processed again
and again.

Fixes hashicorp/consul#7960
Fixes hashicorp/consul#8179