remove need for nil checks around statsd metrics

[jmhodges]

Currently, we have to check if autographer.stats is nil anywhere we
want to emit a statsd metric. This is error-prone and verbose. Work for
AUT-150 (and more) would be easier if we do this here.

This patch makes the autographer.stats field always non-nil. By
default, autographers created with newAutographer will have a
statsd.NoOpClient object for its stats and if the autograph config
has a statsd server configured, it will be replaced with a real statsd
client when autographer.addStats is called. That addStats call will
now always occur in autograph's main function.

This moves the conditional for checking if the statsd server is
configured into autographer.addStats. However, it would probably be
better in the future for us to have this and the similar
autograph.add* methods moved into the newAutographer contructor.
This, though, at least makes the autographer type a lil safer on
construction.

This means that we use statds.ClientInterface instead of
*statsd.Client everywhere to fit both client types.

Along the way, we also have to fix up the main_test.go that was
reproducing that conditional from the main inside it. We also fix an
signer/xpi test that was depending on a statsd server running but not
actually needing it to finish.

This patch doesn't remove all of the nil checks. A follow up will be
made to do so.

Updates AUT-159
Updates AUT-150

[bhearsum]

This is not a problem with this patch, but this makes me think that we might want to add some sort of check or safeguard that ensures we don't run without statsd in production (and perhaps staging?), which I can't imagine we would ever want to do...

[jmhodges]

This is not a problem with this patch, but this makes me think that we might want to add some sort of check or safeguard that ensures we don't run without statsd in production (and perhaps staging?), which I can't imagine we would ever want to do...

We'd hopefully find out because our alerts would fire with a "not getting data" alarm. Def the next step is to make sure we have alerts in place using this data!

[willdurand]

r+ for xpi/* changes, thanks