Redesign GET /api/deliveryservice_stats for api 3.x to be more flexible

[mitchell852]

I'm submitting a ...

• bug report
• new feature / enhancement request
• improvement request (usability, performance, tech debt, etc.)
• other

Traffic Control components affected ...

• CDN in a Box
• Documentation
• Grove
• Traffic Control Client
• Traffic Monitor
• Traffic Ops
• Traffic Ops ORT
• Traffic Portal
• Traffic Router
• Traffic Stats
• Traffic Vault
• unknown

Current behavior:

The current design of GET /deliveryservices_stats is not very flexible. For example:

it has hardcoded aspects such as:

https://github.com/apache/trafficcontrol/blob/master/traffic_ops/traffic_ops_golang/trafficstats/deliveryservice.go#L62
https://github.com/apache/trafficcontrol/blob/master/traffic_ops/traffic_ops_golang/trafficstats/deliveryservice.go#L70

what if i created a metric in influx called foo.ds.5min, it would not be accessible via this endpoint. The point of this endpoint is to allow system operators to store all types of metrics for a ds in influx and retrieve those metrics via this endpoint which has tenancy baked in.

In addition, totals are calculated based on metric type and seem to assume that everything is "per second"

https://github.com/apache/trafficcontrol/blob/master/traffic_ops/traffic_ops_golang/trafficstats/deliveryservice.go#L350

IMO totals can be calculated by the client from the data returned.

Expected / new behavior:

Design GET api/3.x/deliveryservice_stats to be more flexible and less specific to certain metrics (kbps/tps) or certain continuous queries (i.e. ds.1min)

Minimal reproduction of the problem with instructions:

n/a