add ANSIBLE_STRICT_USER_CHECK_MODE environment variable

[ktdreyer]

Similar to ktdreyer/errata-tool-ansible#217 , we need to optionally surface missing user accounts sooner, in check mode.

1. In some environments (eg production), we don't want to grant the Ansible system permission to manage Koji user accounts, but we do want check mode to fail loudly if the requisite user accounts do not exist for koji_tag or koji_tag_packages. When it fails, administrators will follow the standard (semi-manual) user setup creation processes, or more likely, correct typos.

2. In other environments (eg non-prod, devel environments), we expect to grant Ansible full admin access to manage user accounts. We don't want koji_tag or koji_tag_packages check mode to fail if the requisite user accounts do not exist, because Ansible will create them in the playbook with koji_user in non-check mode.

Let's add a ANSIBLE_STRICT_USER_CHECK_MODE environment variable that controls this behavior:

• When ANSIBLE_STRICT_USER_CHECK_MODE is set to true, we'll fail the playbook run if we're in check mode and any requisite user accounts do not exist. This means we'll verify existence of every user account listed in the packages parameter of the koji_tag and koji_tag_packages modules.

• When ANSIBLE_STRICT_USER_CHECK_MODE is unset or false, we will not check user accounts in check mode (the existing behavior)

Since these getUser checks to the hub are slow and expensive, only perform them if check mode determines that result['changed'] is True.

A future optimization would be to narrow down the conditions further, like only if packages changed, or only test the exact user accounts that Ansible would have added to the tag. Unfortunately the result dictionary does not have that info easily available. From our experience in writing this feature in python-errata-tool, that complicates the implementation, and the best bang-for-the-buck performance optimization is simply checking that result['changed'].

[ktdreyer]

See also #221, discussing improving the No such user exception classes. I think that is a prerequisite for this feature.

Internal Red Hat ticket CWFCONF-883 also tracks this work.

[ktdreyer]

Also, eventually we want to get rid of package lists and owners in Koji. But that would be a more long-term change.