regression - systemd provider does not honor documented enabled states

We found this bug again with puppet-agent 1.9.0

For CentOS:
puppet-agent-1.9.0-1.el7.x86_64

For Ubuntu:
ii puppet-agent 1.9.0-1xenial amd64 The Puppet Agent package contains all of the elements needed to run puppet, including ruby, facter, hiera and mcollective.

The virtlockd/virtlogd services under systemd (both on Ubuntu and CentOS) are being marked as non-idempotent due to
2017-02-02 03:38:31 +0000 /Stage[main]/Nova::Compute::Libvirt::Services/Service[virtlockd]/enable (notice): enable changed 'false' to 'true'
2017-02-02 03:38:31 +0000 /Stage[main]/Nova::Compute::Libvirt::Services/Service[virtlogd]/enable (notice): enable changed 'false' to 'true'

See logs
http://logs.openstack.org/38/393738/15/check/gate-puppet-openstack-integration-4-scenario002-tempest-ubuntu-xenial/55b4fbf/logs/puppet.txt.gz#_2017-02-02_03_38_31
http://logs.openstack.org/38/393738/15/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/ea5b599/logs/puppet.txt.gz#_2017-02-02_03_43_59

Previous bug PUP-6370 was described as:
The systemd provider considers too many states as "disabled" and should probably just simply track the return value of "is-enabled" instead of capturing stdout and comparing it to a static list of knows states. This has the added benefit of us not having to externally track new states added to systemd over time.

This issue was found in puppet-nova's CI where we found that the virtlockd and virtlogd services attempt to be enabled on every run; their "is-enabled" state is "indirect".