Upgrade module depencies version

[cboitel]

While reviewing dependencies on some other poject, i found this one was somewhat suffering from a recurrent update policy which is good security practice in general.

a go get -u reveals the following updates are pending:

-       github.com/armon/go-metrics v0.0.0-20180917152333-f0300d1749da
+       github.com/armon/go-metrics v0.3.10

-       github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c
+       github.com/google/btree v1.0.1

-       github.com/hashicorp/go-msgpack v0.5.3
+       github.com/hashicorp/go-msgpack v1.1.5

-       github.com/hashicorp/go-multierror v1.0.0
+       github.com/hashicorp/go-multierror v1.1.1

-       github.com/hashicorp/go-sockaddr v1.0.0
+       github.com/hashicorp/go-sockaddr v1.0.2

-       github.com/miekg/dns v1.1.26
+       github.com/miekg/dns v1.1.43

-       github.com/stretchr/testify v1.2.2
+       github.com/stretchr/testify v1.4.0

[dnephin]

Thank you for your interest in the maintenance of memberlist!

Since memberlist is a library (not an application), and Go modules use minimum version selection, I believe it is generally a good practice to leave the required versions at the lowest viable version. The versions in the memberlist go.mod are only really relevant for running the tests in this repository.

Any application that uses memberlist should require more recent versions. Updating the go.mod file in this repo to the latest version of everything could make it more difficult to use memberlist. It would mean that someone updating memberlist would be forced to update a lot more dependencies.

If there are specific security problems or bug fixes in our dependencies that impact memberlist , we should definitely update the minimum supported version. Otherwise I think it is better for consumers to leave them as-is.

[cboitel]

As for me the minimum viable version is one not having CVE.

[mandeepbrar]

Getting this error
go: github.com/armon/go-metrics@v0.5.1: parsing go.mod:
module declares its path as: github.com/hashicorp/go-metrics
but was required as: github.com/armon/go-metrics

[paulnpdev]

anyone solve this last one?

[rboyer]

go-metrics upgrades are hard and stalled at the moment. See @jmurret's reply from a PR elsewhere about the challenges of upgrading from armon/go-metrics to hashicorp/go-metrics:

Hi all, we will post a more detailed thread on why this is complicated, but the short gist is that this change has to be consistently updated across the dependency chains of libraries used in an application. go-metrics relies on a singleton sink in global state. If any applications have a mix of armon metrics and hashicorp due to underlying dependencies not aligning on only one of them, metrics will be split among different sinks in the global state.
This change has to be coordinated with changing and releasing this dependency across multiple libraries and applications in a thoughtful way. This PR is taking longer than expected due to the prioritization and coordination of those efforts to ensure a smooth transition. Thank you for your patience and understanding.