…/main/splay"

This reverts commit a1a84cb.

Memoize the jobs so it's clearer which jobs 0 and 1 are.

If puppet.conf was modified, but splaylimit wasn't, then we recalculated
the splay offset. This goes against the desired behavior of only splaying when
the agent is initially started and running every runinterval seconds from that
point forward or until runinterval/splaylimit are changed in the future.

Now the SplayJob remembers its last splaylimit so that it only recalculates
splay if the limit changes. It's important to recalculate splay so that the
agent chooses a slot over the new range, either smaller or bigger than before.

Provide more context when the agent runs so it's clearer whether splay is
enabled and what the limits are. We don't want to do this for the reparse and
signal jobs, because they run every 15 and 5 seconds, respectively.

The info message is of the form:

    Running agent every 20 seconds with splay 5 of 10 seconds

This message is logged whenever the agent is running periodically, not for
onetime runs. Whether we're daemonized doesn't affect the behavior. This is
because we always call Puppet::Daemon#start when running periodically to
run the event loop.

Previously, enabling or disabling splay in puppet.conf did not work if the
agent was already running periodically.

If the agent was started with splay disabled, then enabling it would cause a
NoMethodError, when trying to call Puppet::Scheduler::Job#splay_limit

If the agent was started with splay enabled, then disabling it would have no
effect, since we never recalculated the splay limit.

To handle these cases, always create a SplayJob for the agent_run job and set
its splay_limit to either the limit or 0, depending on whether splay is enabled
or not. Setting a splay_limit to 0 causes the splay to also be set to 0 because
rand(1) always returns 0.

Since splaylimit defaults to runinterval, changes to runinterval affect splay.
Add tests covering cases where runinterval is increased and decreased. It's
important to recalculate splay to reduce thundering herds. For example, if
runinterval is changed from 30 mins to 60 mins, we want the compute a new slot
in the 60 min interval to decrease server load.