Summaries as implemented cannot be aggregated in a meaningful
way. Partitoning them by status code and method only made sense if we
were interested in the individual latency and size of e.g. GET request
that result in status 503. In general, that's not the case. Most of
the time, the user will be interested in the latency and size of _all_
HTTP requests.
(With future changes to client_golang, we will consider making the
HTTP instrumentation configurable, e.g. to handle the case where the
user is only interested in the latency of successful requests.)