[ZD-19670] CloudBees customer reported that the quite period checkout be...

...haviour has anomolous logic that can result in failed builds

- This is likely where there is a delay between the build leaving the quiet period and the build starting
- If there is a commit during that period of time then the build may checkout an inconsistent state
- The solution is to use the time when the quiet period is completed as the timestamp for the checkout
- Obviously people may prefer the original behaviour in some cases
Yes but the checkout time is the time of start building, not the time of exit quiet period.

The SCM trigger is special in this case because it was started by a commit and there could be another commit by the time the actual commit starts executing.

The issue here is when you have a system nearing resource limits. The build is triggered, the quiet period runs down, and then the build is waiting for an executor... while waiting there are some commits, then the build starts and sucks in those commits... it would be ok if the commits that rolled in caused the quiet period to be reset as then you would at least get `commits + quiet period + execution delay + commits + quiet period + execution delay`, but instead you get `commits + quite period + execution delay + partial commits`