perf: limit goroutine usage while unmarshaling prometheus and influx points/values

[crandles]

This PR adds a simple goroutine limit for the prometheus/influx backends "unmarshal time series" codepaths, using errgroup to limit goroutine creation to the current GOMAXPROCS value.

---

Not having a limit seems like a bad idea for these particular goroutine creations. I debated on removing these goroutines entirely, but settled with mapping this to the GOMAXPROCS value (Exposing via config will require many more LOC updates). If we want to remove concurrency here, I can pull that out of my git stash.

The rest of our goroutine creation seems to be more naturally tied to e.g. the number of series being processed and easier to predict (compared to goroutines per each value/point).

There's still a chance for somewhat-unbounded goroutines to be created -- given trickster is still accepting requests, or depending on the number of timeseries a result may contain

If we wanted to improve in that area, we'd need more drastic changes, some sort of generic worker pool concept. On the simpler side, perhaps we could recommend doing so indirectly via rate limiting + http.Server options?

[coveralls]

Pull Request Test Coverage Report for Build 20733330116

Details

• 12 of 12 (100.0%) changed or added relevant lines in 2 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.005%) to 72.119%

---

Files with Coverage Reduction	New Missed Lines	%
pkg/proxy/engines/cache_read.go	2	81.82%

Totals
Change from base Build 20349547424:	-0.005%
Covered Lines:	14915
Relevant Lines:	20681

---

💛 - Coveralls