Monitor self-test to see if there are any problems and act accordingly

[codefromthecrypt]

Via #150, we are currently downloading zipkin-server via Jitpack. There were some questions about if this is reliable, or if the lazy build of the server notably impacts master performance in a way that matters.

Since the alternative is hacky and verbose, let's just monitor and see if we need to change before using the alternative below:

# This is a parsing alternative to returning the constant: 
#   
# We are doing this to avoid a delay as snapshots are built lazily in Jitpack,
# and also avoid insecurities about the version built by Jitpack.
zipkin_snapshot_url() {
  zipkin_base=https://oss.jfrog.org/oss-snapshot-local/io/zipkin/zipkin-server
  zipkin_version=$(curl -sSL $zipkin_base/maven-metadata.xml | sed -n '/<version>/s/.*<version>\([^<]*\)<\/version>.*/\1/p'|tail -1) && \
  zipkin_build=$(curl -sSL $zipkin_base/$zipkin_version/maven-metadata.xml | sed -n '/<value>/s/.*<value>\([^<]*\)<\/value>.*/\1/p'| head -1) && \
  echo $zipkin_base/$zipkin_version/zipkin-server-$zipkin-exec.jar
}

[codefromthecrypt]

I added output of the /info endpoint into the test script so we can verify if indeed there are hash problems. probably a good idea anyway

+curl --silent localhost:9411/info
2019-09-26 13:37:18.731  INFO 5466 --- [orker-epoll-2-2] c.l.a.i.JavaVersionSpecific              : Using version specific APIs from Java9VersionSpecific
{
  "zipkin": {
    "version": "2.17.1-SNAPSHOT",
    "commit": "844c43b"
  }
}