Plan rejections occur when the scheduler work and the leader plan
applier disagree on the feasibility of a plan. This may happen for valid
reasons: since Nomad does parallel scheduling, it is expected that
different workers will have a different state when computing placements.

As the final plan reaches the leader plan applier, it may no longer be
valid due to a concurrent scheduling taking up intended resources. In
these situations the plan applier will notify the worker that the plan
was rejected and that they should refresh their state before trying
again.

In some rare and unexpected circumstances it has been observed that
workers will repeatedly submit the same plan, even if they are always
rejected.

While the root cause is still unknown this mitigation has been put in
place. The plan applier will now track the history of plan rejections
per client and include in the plan result a list of node IDs that should
be set as ineligible if the number of rejections in a given time window
crosses a certain threshold. The window size and threshold value can be
adjusted in the server configuration.

…e marked ineligible

Simplify the interface for `BadNodeTracker` by merging the methods `Add`
and `IsBad` since they are always called in tandem and reduce the number
and level of log messages generated. Also cleanup expired records to
avoid inifinite growth the cache entry never expires.

Take explicit timestamp to make tests faster and more reliable.

Set the timestamp for a plan apply operation at request time to avoid
non-deterministic operations in the FSM.

Using a pointer allow us to differentiate between a non-set value and an
explicit `false` if we decide to use `true` by default.