[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
@jglick well if User A triggers the build it might break because User A does not have permission to access the deployment credentials... or a build triggered by a GitHub Pull Request might run in a sandbox and skip deployment while a regular build from the direct GitHub trusted code repo might run outside the sandbox and follow through with deployment.

I think the principle of causes affecting build behaviour is well established... no matter how dirty it might feel ;-)

The real issue here is that Jenkins has never really had the actual implementation of quiet period that cruise control had... and the "quiet period" that Jenkins has does something different, and thus people end up trying to work-around and nobody actually asks what the real requirement is in the first place...

of course the real requirement is atomic commits, but I don't see CVS supporting those any time soon.

CruiseControl's quiet period would basically wait for a lull in commits of at least `X` seconds before starting a trigger... the perfect storm of commits would result in no builds being triggered until the commits stop.

Jenkins instead says, I am going to start the build at `now+X`.... defanging the perfect storm of commits problem... but if you checkout based on when the build starts there could be another set of commits from the next user that are partially included.

So the fix for SCM triggered actions is to watch for the quiet period being complete, so that we can catch the appropriate end of the commit storm window. Perhaps a better solution would be to capture the SCMTrigger timestamp itself and then just add the quiet period on to that and use that as the time-stamp for SCM triggered builds... same could be applied to other remote triggers if the time of triggering is recorded... but that would require changes in core