Refactor driver timeouts

[sunce86]

Description

Tackles checkboxes 1 and 2 from #2041 (comment)

Changes

This is my attempt to make timeouts more explicit and clear.
First, we split the deadline given to driver into 3 pieces:

1. Solving time given to solvers
2. Competition time, used to validate, merge, simulate, score and rank solutions.
3. Http delay, to cover potential slow propagating of http response back to autopilot (http_delay)

The time is split in a following way: competition time and http delay are values read from the configuration (so hardcoded), while the solving time is whatever is left after deducting those two from the deadline given to driver.

It's important to note that:

1. Http delay is reduced from driver deadline at the very beginning of the solve/quote handling, because it's a non-domain information. Core domain logic doesn't care about network delays.
2. Competition time is reduced from deadline in the domain, because how we split given time to solving and competition is actually domain related. For some solvers we want 19s for solving and 1s for competition, while for some others like Baseline, we might want 10s for solving and 10s for competition.

Default values are set to something like:
/solve: 20s given to driver, http delay is 0.5s, competition is 4.5s, solving time 15s
/quote: 3s given to driver, http delay is 0.5s, competition time 1s, solving time 1.5s

Release notes: check the default timeouts and if they need to be adjusted.

[MartinquaXD]

I think this is not the longterm solution we should pursue but if you think this gets us closer to deploying on prod mainnet we can try it out.

[fleupold]

This PR is quite a bit of non-trivial logic around different parts of the whole driver stack. I wonder if the logic could be smaller/more contained if we

1. Keep the timing math local to the Deadline and expose the different final deadlines we are interested in (for solvers and the merging)
2. Not differentiate for now between quote/solve

I'd also like for percentages to be the same format we have them for most of our other configuration parameters.

[fleupold]

I like this approach much better. Just some nits around naming and use of conversion traits, but nothing blocking.