(#19876) Fix crontab regression in resource matching

The logic for matching new resources with exiting unmanaged cronjobs
has been reworked during the fix for #16809. Somehow, this lead to
a new issue which caused spurious matches, e.g.:

10 * * * * /bin/true

and

cron { "blank": command => "/bin/true", ensure => present }

would now match. At least puppet will not try to change the name of the
record (i.e., the 'Puppet Name:' line). But the new entry will not get
added either. It still works if there is a non-matching time field, e.g.

cron { "blank": command => "/bin/true", hour => 1 }

but without such fields, the behaviour is wrong.

The match method (in the crontab provider) will expressly ignore named
records on disk. This is safe to do; if the resource does have the
same name as the on-disk record, the match method will not even get invoked.

There is no scenario in which we'd want differently named records to be
matched with a resource. If an on-disk record has a name, it either is
managed through another resource, or it used to be managed. Either way,
the resource in question needs adding or matching to a different record.
(maint) update cron whitespace strip acceptance test

Since f5d236702 leading and trailing whitespace was stripped from the
cron command to ensure writing cron entries is idempotent. This made the
cron `should_not_rewrite_with_trailing_whitespace.rb` acceptance test
meaningless. This commit updates the acceptance test to confirm the fix
for #656 and updates the test name to reflect the expected behavior.
Merge pull request #1566 from adrienthebo/maint-cron_acceptance_test_failure

(maint) update cron whitespace strip acceptance test
(#12493) Add note that `user` defined in a scheduled_task resource must be a privileged user.

The scheduled_task resource includes a note about issues surrounding the use of the 'SYSTEM'
user and recommends choosing another user to run the scheduled task, or altering the security
policy to allow the 'SYSTEM' account to run scheduled tasks. The note does not mention
that puppet must be running as a privileged user to manage scheduled tasks in order to avoid
'access denied' errors.

This commit corrects the issue by adding a note that puppet must be running as a privileged
user to manage scheduled tasks and avoid 'access denied' errors.
(#19805) Report failures to restart in exit code if requested

Documentation to --detailed-exitcodes states that mask 0x4 is applied in case
"there were failures during the transaction." Currently only failures to change
resource state are reported, failures to restart the resource are still ignored.

Only change (code=2) to Exec['/bin/true'] is considered here:

  $ puppet apply --detailed-exitcodes -e 'service { "duckfaced": restart => "/bin/false", ensure => running, status => "/bin/true" } exec { "/bin/true": notify => Service["duckfaced"] }'
  $ echo $?
  2

Needless to say, information about failed restarts is usually as important to
the user as the status changes, since they usually mean that desired
configuration is not in effect.

This change makes Puppet consider information about failed restarts when
setting the failure bit.

Another possibility to avoid loosing the information  would be to introduce
another bit in the exit code mask, but that would change semantics with respect
to existing documentation and thus probably be more confusing.
Merge branch 'pull-1541'
Merge pull request #1565 from ffrank/ticket/master/19876-crontab-match-regression

(#19876) Fix crontab regression in resource matching
Merge pull request #1567 from pdxmph/windows_scheduled_task

(#12493) Docs: Note that `user` defined in a scheduled_task resource must be a privileged user