Implement scaling latency metrics through logical clock

[Omrigan]

Fixes #594.

[Omrigan]

@sharnoff can you take a look, if you have a moment? This is very WIP, I didn't update the tests or tested it.

Looking at the logic around agent's state -> does this logic of clock propagation looks sound to you? Can I make it simpler and more compact somehow?

[sharnoff]

Had a look - I think I'm struggling to get the big picture of what the intended flow within the autoscaler-agent state machine is (mostly because the existing code is quite complicated, and the new stuff doesn't yet have comments).

Broadly I think it should be ok, but do you have a quick (1-2 paragraph) explanation of how the clocks are supposed to flow?

(IIUC, currently the "desired logical time" stored in the plugin/monitor/neonvm state is basically the logical time of the most recent scaling that the component has completed successfully? If so, AFAICT there are still some subtle edge cases, but they shouldn't require major changes to accommodate.)

Would be good to discuss on Monday 😅

---

All that aside, one thing I noticed: In a lot of places, there's variables like desiredClock or desiredLogicalTime -- IMO, this reads with desired as an adjective affecting the clock/logical time, which I guess is not what's intended. I wonder if it'd be better to refer to these more like timestamps, e.g. "tsOfDesired" or "desiredAtTime" etc. (or event just "desiredAt"?)