Add started RPC metric for client and server side (#1283)

* Add started RPC metric for client and server side

Adding GC stats to runmetrics plugin (#1207)

* use derived cumulative where applicable
* add a flag to control derived cumulatives

Defer IDGenerator initialization until first use (#1228)

Initializing the `IDGenerator` from `init()` means that any downstream
project which transitively imports this package somewhere in its
dependency tree will incur `getrandom()` syscalls it has no control over
at startup.

This causes problems for us in
[Ignition](https://github.com/coreos/ignition), where we're transitively
pulling in this package via cloud.google.com/go/storage. Ignition runs
very early during the boot process, which means that even though this
isn't using `GRND_RANDOM`, the `getrandom` syscall can block until the
entropy pool is ready. This is a real problem when running in VMs on
systems which don't provide a virtualized RNG device (such as VMware) or
which lack RDRAND.

I can't find a good reference for this, but I think in general it should
be considered good practice to avoid I/O like this in `init()` in favour
of a more lazy approach (or an explicit `Initialize()` function for
clients to call).

Otherwise, *every* program which pulls in the package will pay for it,
whether or not they intend to actually make use of the functionality
those syscalls are priming. (While it's not relevant here, another
advantage of not using `init()` for this is that I/O is fallible, and
`init()` semantics means errors can't be handled sanely.)

Let's rework things here so that we don't actually initialize the
`IDGenerator` fields until the first time it's used.

Initialize View Start Time During View Registration (#1215)

* Initialize view start time during view registration

* Remove unnecessary start time initialization from reportUsage

* Remove unnecessary start time check in toMetric

Version 0.22.3

Version 0.22.2

Version 0.22.1

Version 0.22.0

Version 0.21.0