In our custom package manager salt module, add a special case to handle
Salt downgrade, as `yum` do not handle downgrade dependencies properly
you need to provide all dependencies explicitly.

Sees: #2523

Until now, we use `module.run` to execute `test.ping` after restarting
`salt-minion`. The `module.run` state has `changes` though,
unconditionally. As such, when re-running any state including
`salt.minion.running` (e.g., all highstates), this causes changes to be
reported.

Currently, when bringing a cluster to highstate, only these `module.run`
'states' cause any 'changes' to be reported, giving the impression our
states are not idempotent. The `test.ping` call is inherently
idempotent though...

As such, changing the approach slightly and instead of using
`module.run`, running `test.ping` from a `__slot__` call whose result is
set as the `result` of a `test.configurable_test_state` state, wich
`changes` set to `False`. As such, this state will now properly fail
when `test.ping` returns `False`, but no `changes` will be reported when
this state is applied.

(cherry picked from commit b26d64a)

`module.wait` add some `changes` to the output when a `test.sleep` does
not do any change, so use a `test.configurable_test_state` with a `slot`
instead so that this state never report any changes (which is expected)

Install salt-minion salt state may also upgrade and downgrade
salt-minion package, and this salt version change may have impact on
the running salt states, so make this salt states running at the end of
the state.

Refs: #2524

In `deploy_node` orchestrate during `Reconfigure salt-minion` salt state
we may upgrade, downgrade salt-minion package and restart salt-minion
service so salt-minion may miss some of the salt-master job query,
increase timeout so that minion have time to upgrade, downgrade and
restart if needed

Fixes: #2524