Update revision-pinned dependencies to release

[cpu]

I ran Boulder through glide-report -no-color to try and identify dependencies we are pinning to a revision instead of a release, or have fallen behind from the latest release.

The following imports were all "Using development revision between Semantic Version releases":

• github.com/cactus/go-statsd-client - Updates go-statsd-client to 2.0.2. #2343
• github.com/cloudflare/cfssl - there is a WIP branch for this, Update cfssl, CT, and OCSP dependencies #2170
• github.com/go-sql-driver/mysql - Updates go-sql-driver dep to tip of master. #2344
• github.com/jmhodges/clock - Updates clock to v1.1. #2353
• github.com/letsencrypt/go-safe-browsing-api - rather than update this fork we should solve this one by implementing Switch to Google's Safe Browsing implementation #1863
• github.com/prometheus/client_golang - Update prometheus client_golang dep to 0.8.0 #2358
• google.golang.org/grpc - Updates google.golang.org/grpc to v1.0.3. #2359
• github.com/matttproud/golang_protobuf_extensions (Note: Transitive import) - the only release for this library is v1.0.0. Since only two minor commits have been added since then it doesn't seem worth asking for a v1.0.1 release.
• github.com/letsencrypt/pkcs11key - Updates pkcs11key dep to v1.0.0 #2369

For each of the above, we should either the update the dependency (following the CONTRIBUTING.md process!) to a semantic version release, or document why we are pinned to a specific development revision.

[cpu]

Updated to mark go-safe-browsing-api and cfssl as not-required and in-progress respectively. The CFSSL pr (#2170) needs some tests fixed and to be confirmed as updating to a release and not another dev commit.

[rolandshoemaker]

Could you provide a rational for only using release versions instead of commits? Often we need to make changes to upstream libraries which would then be blocked on waiting for a new release including that change to be made.

[cpu]

@rolandshoemaker I don't think we need to stop the practice of pinning to a commit when we're waiting on upstream libraries to include changes we need, I just think that should be a documented event and we should aim to be using releases for everything else. I think it makes it easier to stay on top of security updates in upstream libraries this way. Does that make sense?

[rolandshoemaker]

Yup, works for me.

[cpu]

Our github.com/go-sql-driver/mysql dependency is pinned to a specific revision off of the 1.2 release. Ideally we would bump this to the latest tagged release but upstream is not yet using semantic versioning and there is significant work in master since the 1.2 release with no 1.3 tag available. I propose we update this dep to master and revisit when there is a 1.3 release.

[cpu]

We're pinned to 880ee4c335489bc78d01e4d0a254ae880734bc15 for github.com/jmhodges/clock, which is currently master's tip and newer than the 1.0 tagged release. There's nothing to do for this dep. unless upstream cuts a release.

[jsha]

I can ping upstream for github.com/jmhodges/clock.

[jsha]

Upstream Clock now has a v1.1.

[cpu]

Added a comment for github.com/matttproud/golang_protobuf_extensions. There's only a v1.0.0 release and we're pinned to the tip of master, which is only two minor commits ahead of v1.0.0. It doesn't seem worth bugging upstream for a v1.0.1 release, especially for a transitive import.

[cpu]

RE: the merged Prometheus client update, from @jsha:

Note: This actually takes us to a slightly earlier revision of the Prometheus client (v0.8.0 was cut Aug 17, but we were previously vendored to an Oct 26 commit). However, it doesn't lose us any functionality or bug fixes. It gains us a couple of spelling errors in comments, but that's no big deal. I think it's worthwhile to take this patch in order to be vendored at a specific semver release.

[cpu]

Added PKCS11Key to the list with #2369