fix: histogram upper bound is too low

(i believe this closes #151)

i was seeing panics happening when trying to print stats while load-testing a relatively inefficient, but not THAT inefficient site

did a bit of digging and realized the upper bound of the histogram implied an upper limit of 3.6s or 3600ms, which is obviously trivial to exceed when hitting any kind of relatively expensive API

it looks like the histogram initialization was just copy-pasta'd from the example in the docs:

however, in drill's case, it's actually measuring in microseconds, not milliseconds (and then divided down in all the stats, as evidenced by the fact that the request duration (already in ms) is being multiplied by 1000 before appending to the histogram:

as such I made two changes:

introduce a max timeout, so we can reasonably set an upper bound that should be impossible to ever exceed
convert the max timeout to microseconds and use that as the histogram's upper bound

if you're against the MAX_TIMEOUT_SECONDS constant that I introduced, I'm ok w dropping it but in that case, we either continue to risk panics or we have to find a smarter way to derive the histogram's upper bound. we could base it on the actual timeout option, but the config is initialized inside of benchmark::execute & not returned back out, so it would require a more structural change in order to achieve this which I wanted to avoid in this PR

do let me know if there's a more preferrable solution to the issue, but hopefully this is at least a quick and dirty solution so that 3.6s+ requests don't cause drill to panic :3

fcsonline / drill

fix: histogram upper bound is too low #174