add skip_verify for service.enabled and .disabled

[jigish]

What does this PR do?

Adds the skip_verify option for service.enabled and service.disabled.

When running service.enabled or service.disabled, salt verifies that the service is 'available'. This option allows the user to skip that verification for cases that it doesn't make sense. For example, while running salt in a chroot environment (like packer's salt-masterless provisioner while using the amazon-chroot builder), systemctl status fails as it is invalid. Without skip_verify, this would cause the service.enabled state to fail as well.

What issues does this PR fix or reference?

#38751 -- Doesn't fix, just supplies a workaround.

Tests written?

No

Commits signed with GPG?

Yes

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

[terminalmage]

I'm curious how this would help, if the service name is invalid, wouldn't enabling/disabling it also fail?

% sudo systemctl enable foo
Failed to enable unit: Unit file foo.service does not exist.
% echo $?
1
% sudo systemctl disable foo
Failed to disable unit: Unit file foo.service does not exist.
% echo $?
1

It seems to me like this just kicks the can to a further point where it will also fail.

[jigish]

You're absolutely right for cases in which the service name is invalid, which is why the option is defaulted to False.

The skip_verify option I've added is intended to be used in cases where the available check itself is not applicable and/or invalid but the service name is valid. In chroot environments, systemctl status calls fail even for valid service names as systemd seems to consider it an invalid use case. In those cases you could use skip_verify to skip that and directly systemctl enable which will work just fine. This is especially important while using salt to provision an AMI via amazon-chroot.

That being said, I've implemented this as a stopgap. It may be worth modifying the systemd module itself to not run status in chroot environments. I just have a lot less experience with the other service modules so I'm not sure if the same change is needed in them.

[terminalmage]

I don't like that you've inserted this skip_verify argument such that it is required to be passed every time the function is invoked. If we expect the vast majority of the invocations to be False, then the skip_verify argument should be moved until after result and should have a default value of False. Then we don't have to pass a False in most of the calls to _enable() and _disable(), and in the few cases where we are passing through the value from the state, we can simply pass skip_verify=skip_verify.

[jigish]

@terminalmage - Just made the requested changes. Thanks for taking a look!