Currently, after 4 failed constraint checks, we suspect the constraint

Currently, after 4 failed constraint checks, we suspect the constraint
of being wrong, not the NTP responses, reset it and query it from all
the constraint servers all over again.  This is turned out to be a bit
aggressive because it could get triggered with just a few bad NTP
peers in a larger pool.  To avoid constant reconnections, scale the
error margin with the number of resolved NTP peers using peer_cnt * 4.
This way a single or a few outliers in a NTP pool cannot trigger
reconnecting to the constraint servers immediately.  More NTP peers,
less reason to mistrust the constraint.

Found by dtucker@
OK deraadt@