(#3220) crontab: allow purging unmanaged resources

The problem was that unmanaged cronjobs would be parsed, but
not implicitly named.

Workaround: Pick an implicit name. It's derived from the command.
The provider will never put this implicit name into a crontab file
when writing it back to disk.

The names are not unique if several unmanaged jobs execute the same
command. That's a wrinkle and not mission critical, but it can
be surprising for users, because the "duplicates" will not be
purged during the first run.
(#3220) make sure that generated cron resources belong to the correct user

This solves a testing issue that resulted from the #2251 fix. The new
problem is that resources are no longer just looked up by name. Now, the
resource's user property has to match the file being read from disk.
The problem with generated resources is that they use the default user
(i.e., the user running the spec test). Therefor, the resources would now be
considered independent from the crontab records from the testing fixture.

It's fixed by making sure that the respective user property matches the crontab
from which the resources are generated. This is done while the resources are
marked as "being purged" by overriding the Type#purging method.
(#3220) fix a cron testing quirk with potential benefits for normale operation

The integration test for the purging of unmanaged cron resources had
the bizarre side effect of writing vestiges of the fixture to ./$USER
whenever the test was run.

The reason were default should-values for the target property of cron
resources. Per default, the target for any cron resource is the current
user. When generating resources (through the instance method), the
default is erronously used.

When purging, we can fix this by forcing the should-value of each
resource being purged to be the file the resource was generated from.
This is done in the override of the purging method.
(#3220) make the unit test "generating cron resources" match the new behaviour

To allow purging of unmanaged resources, they are now implicitly named.
The unit test must take that into account.
(#3220) save overhead in cron type unit test and add cleanup

As it was, the unit spec for the cron type would register a mock provider
before each example. Add the :all parameter to 'before' to make that happen
only once.

There was a new issue with the integration test for the #3220 fix. The reason
was that the mock provider from the cron unit test would remain in the list of
suitable providers. Purging relies on Type.instances, which in turn tries and
invokes the instances method of all suitable providers. Prevent issues by
removing the mock provider from the list.
(#3220) uniquify implicit record names

Adds an numeric suffix to the artifical name that gets generated for
unnamed records in crontabs. It will suppress naming collisions for cronjobs
that use the exact same command string.
(PUP-649) Use class instance variable

Accessing a class variable from the class produces a warning on ruby
1.9.3. We can instead just use the instance variable, which is also on
the class, but is safer to use.
(PUP-649) Loosen checks for crontab provider

The tests for the crontab provider exhibited an order dependent failure.
If the spec/integration/provider/cron tests were run before the
spec/unit/provider/cron tests then the global counter that is used by
the crontab provider would not be at the expected value. This isn't
really a problem in practice, but the expectations in the tests were for
a specific count. This updates the checks so that they are resilient to
the exact numbers chosen.
Merge branch 'pr/2024'

* pr/2024:
  (PUP-649) Loosen checks for crontab provider
  (PUP-649) Use class instance variable
  (#3220) uniquify implicit record names
  (#3220) save overhead in cron type unit test and add cleanup
  (#3220) make the unit test "generating cron resources" match the new behaviour
  (#3220) fix a cron testing quirk with potential benefits for normale operation
  (#3220) make sure that generated cron resources belong to the correct user
  (#3220) crontab: allow purging unmanaged resources

Closes GH-2024
(PUP-1327) add the file attributes owner, group and mode to nagios types

It's desirable to make it possible to write manifests such as

nagios_host { "hostname":
  ... # nagios properties
  group => "nagios",
  mode  => 640,
}

instead of the workaround of

nagios_host { "hostname":
  target => "/etc/nagios/hostname.cfg",
  ...
}
file { "/etc/nagios/hostname.cfg": ... }

To make this possible in a simple fashion, just add the file properties
owner, group and mode to each nagios type as parameters. If either of them
is specified, the nagios resource generates an additional file resource
and passes the parameters as should-values of the respective properties.
(PUP-1327) simple unit test for the new nagios parameters

For now, only test for the presence of the parameters. Their function should
be tested in an integration spec.
(PUP-1327) integration spec for the nagios type

This is a very rough draft for a spec test wrt. the "mode" parameter.
Testing group and owner is difficult since unprivileged rspec users
cannot use chown or chgrp.

This is open for discussion and should be revised before merging.
Merge branch 'pr/2060'

* pr/2060:
  (PUP-1327) integration spec for the nagios type
  (PUP-1327) simple unit test for the new nagios parameters
  (PUP-1327) add the file attributes owner, group and mode to nagios types

Closes GH-2060