Honor stale=update_after

If we were aiming for more of a "normal" scale, I'd have each view have
a goroutine with a channel for synchronizing around view updates.  A
regular view update would send in a response channel it could wait on
that would let it know the view had been processed.  update_after would
send in a buffered response channel and just drop it.

The application would be similar, though -- a deferred message send
letting the view engine pick it up after the request completed.

But because of how we have these things come and go, I did a plain ol'
ephemeral goroutine spawned right at the end of the request for the
view.

cbugg: close bug-591
Added ServerStats struct.
Tracking stats of # accepted, closed, open conns.
REST /_api/stats URL.
Placeholder web U/I for server stats.
Web UI currently expects 1 sec stats intervals.

This should be calculated based on the server's stat-agg-freq but for
now just match it all to 1 sec for easier demo-ability.
Web U/I for server stats, and REST api.

Following/reusing the stats aggregation / passivation approach from
the existing bucket stats features.
Don't log when auth verifying stats REST get's.

The javascript web U/I asks every second when on a chart/graphs page,
so it's too spammy.
Try to guess a local address for broken HTTP clients.

cbugg: close bug-555 bug-594
Return the guess address state after test.
Array-based ring implementation.
PushErr/PushLog() for a Bucket.

Expanded (and renamed) the statsLock to also help cover the errs and
logs rings.
Invoke PushErr/PushLog during map func.
Bucket.Errs()/Logs() return the last errors/logs.
REST /_api/buckets/BUCKET/errs & logs.
TestRestGetBucketErrs/LogsEmpty().
Move FileService.OpenFile() to file_server.go.

It lives nearer to all the other FileService methods.