The usage of module_defaults allows to reduce the size of the tests and
to have the needed information in the tasks only. The default values for the
parameters are automatically passed to the module by Ansible.

It is not possible to use a module group for module_defaults as this could
only be done with Ansible Collections. The tests are also used upstream and
downstream without a collection.

Without groups of a collection it is needed to add the defaults for all
modules separately.

Simple example:

    module_defaults:
      ipahost:
        ipaadmin_password: SomeADMINpassword
        ipaapi_context: "{{ ipa_context | default(omit) }}"

Several module example using YAML anchors and aliases:

    module_defaults:
      ipahost: &ipa_module_defaults
        ipaadmin_password: SomeADMINpassword
        ipaapi_context: "{{ ipa_context | default(omit) }}"
      ipauser: *ipa_module_defaults
      ipagroup: *ipa_module_defaults

The documentation for "become" and "gather_facts" has been updated to
make sure that these parameters are enabled only in new tests if it is
really needed.

The values "yes" and "no" will not be valid in the future for bool
parameters. Therefore "yes" and "no" have been replaced by "true" and
"false".

The parameter argument spec of name was missing the closing bracket. The
bracket has been added.

When testing the number parameters for new_module, the
`github_user` was not being taken into account.

new_module was always failing with "github_user is not valid". The wrong
variable was checked: $githubuser instead of $github_user.

ipaserver: Do not enable random serial numbers by default

ipaserver_random_serial_numbers was enabled by default in
roles/ipaserver/defaults/main.yml. This should not be the default and
also resulted in issues in all IPA versions that do not support RSN.

The parameter now defaults to false.

ipagroup: Fix ensuring external group group members (without trust-ad)

roles/ipaserver: Allow deployments with random serial numbers

Update `EXAMPLE` sections for multiuser and multihost handling.

Since FreeIPA version 4.10 it is possible to deploy servers that use
Random Serial Number v3 support for certificates.

This patch exposes the 'random_serial_numbers' parameter, as
'ipaserver_random_serial_numbers', allowing a user to have random serial
numbers enabled for the domain.

The use of random serial numbers is allowed on new installations only.

[RFE] Allow multiple groups creation

Ensuring (adding) several groups with mixed types external, nonposix
and posix require to have a fix in IPA:

    FreeIPA issue: https://pagure.io/freeipa/issue/9349
    FreeIPA fix: https://github.com/freeipa/freeipa/pull/6741

The simple solution is to switch to client context for ensuring several
groups simply if the user was not explicitly asking for the server context
no matter if mixed types are used.

Adding an option `groups` to create multiple groups in one operation.
Adding tests (present/absent/external/nonposix) with server and
client context.
Simple example of `groups` option:
```
tasks:
- name: Ensure 2 groups are present
  ipagroup:
    ipaadmin_password: SomeADMINpassword
    groups:
    - name: group1
    - name: group2
```

Signed-off-by: Denis Karpelevich <dkarpele@redhat.com>

Due to an API misbehaviour in FreeIPA, ipaexternalmembers need to be
treated differently than other group members parameters. Even an empty
array triggers all tests for external members, including the check for
installed dcerpc bindings.

Therefore ipagroup module has been changed to not set ipaexternalmember
to an empty list if there are no external members to be added or
removed.

ipaclient: Defer krb5 configuration fix

ipareplica/server: Enable removal from domain with undeployment

Ansible lint fixes

New variables have been added to ipareplica and ipaserver role to enable
the removal from the domein with the undeployment.

`ipaserver_remove_from_domain`
This enables the removal of the server from the domain additionally to the
undeployment.

`ipaserver_remove_on_server`
The value defines the server/replica in the domain that will to be used to
remove the server/replica from the domain if
`ipaserver_ignore_topology_disconnect` and `ipaserver_remove_from_domain`
are enabled. Without the need to enable
`ipaserver_ignore_topology_disconnect`, the value will be automatically
detected using the replication agreements of the server/replica.

For the replica role it is possible to use the server variables, but
also the replica versions: `ipareplica_remove_from_domain` and
`ipareplica_remove_on_server`.

The already existing parameters `ipaserver_ignore_topology_disconnect` and
`ipaserver_ignore_last_of_role` have been added to the README files for
server and replica with descriptions. The same for the replica versions
of the parameters.

The ipareplica role is not calling the `ipa-server-install` anymore, it
is instead using (including) the server role for the task.

The new module `ipaserver_get_connected_server` has been added to the
server role to be able to get a connected server using the replication
agreements. This module is only used if
`ipaserver_ignore_topology_disconnect` is not needed.

The latest ansible-lint failes for the tasks that are using
"when: sid_disabled.changed" with the error
"Tasks that run when changed should likely be handlers.". As
these tasks are tests and it would not make sense to use handlers here,
the tasks have been marked as noqa 503.

The cleanup of the root IPA cache was depending on the result of the
ipaserver_enable_ipa and ipareplica_enable_ipa tasks. Instead of
"when: something.changed" a handler should be used instead. As
"/root/.ipa_cache" should be removed always (same in command line) the
removal of the file has been moded into the always section and does not
need a when anymore.

The parameters nameservers and searchdomains had both the alias "cn".
Both aliases have been removed.

The alias for usercheck in argument_spec was "ipapwusercheck" instead of
"ipapwdusercheck".

The types for the parameters action and state have been missing in the
DOCUMENTATION section of the module.

With the fix to defer creating the final krb5.conf on clients a bug has
been introduced with ipaclient_fix_ca: The krb_name parameter that
points to the temporary krb5 configuration was not added to the module

Without this the server affinity is broken for allow_repair and additionally
ipaclient_fix_ca could fail if krb5 configuration needs to be repraied
and also CA needs to be fixed.

The krb_name parameter has been added to ipaclient_fix_ca and is also
properly set in tasks/install.yml.

With the fix to defer creating the final krb5.conf on clients a bug has
been introduced with ipaclient_setup_nss: The krb_name parameter that
points to the temporary krb5 configuration was not added to the module.

With a properly configured DNS (like for example IPA DNS) the krb TXT
records have been present in the DNS configuration. These have been used
automatically as a fallback and broke server affinity for the client.
Without the TXT records creating the IPA NSS database failed with
 "Cannot find KDC for realm ..".

The krb_name parameter has been added to ipaclient_setup_nss and is also
properly set in tasks/install.yml.

ipauser: Better description of UID and GID parameters

ipareplica role: Remove usage of undefined parameters.

Some ipareplica role had a few module calls with parameters set like
'some_argument | default(omit)' that were not actually available in such
modules. If a user provided 'some_argument', the paramater would then
be passed to the module and ipareplica deployment would fail.

By removing the parameters from the 'install' task, ipareplica
deployment works even if the variables are set by the user.

ipahost: Make return value depending on hosts parameter

The way how randompasswords are returned by the ipahost module depends
so far on the number of hosts that are handled by the module.

This is unexpected if for example a json file is provided with the hosts
parameter. As it might be unknown how many hosts are in the json file,
this behaviour is unexpected. The return should not vary in this case.

This chamge makes the return simply depend on the use of the hosts
paramater. As soon as this parameter is used, the return will always be:

"host": { "<the host>": { "randompassword": "<the host random password>" } }

In the simply case with one host it will be still

"host": { "randompassword": "<the host random password>" }

This change for ipahost is related to the ipauser PR #1053.

ipauser: Make return value depending on users parameter

ipaclient: Defer creating the final krb5.conf on clients

Add subid option to select the sssd profile with-subid.

This is an ansible-freeipa update for the freeipa RFE:
https://pagure.io/freeipa/issue/9159


"`ipa-client-install` should provide option to enable `subid: sss`
in `/etc/nsswitch.conf`".

This option allows to configure authselect with the sssd
profile + with-subid feature, in order to have SSSD setup as
a datasource for subid in /etc/nsswitch.conf.

The default behavior remains unchanged: without the option,
/etc/nsswitch.conf keeps the line subid: files

Signed-off-by: Denis Karpelevich <dkarpele@redhat.com>

Migrated to SPDX license.

The way how randompasswords are returned by the ipauser module depends
so far on the number of users that are handled by the module.

This is unexpected if for example a json file is provided with the users
parameter. As it might be unknown how many users are in the json file,
this behaviour is unexpected. The return should not vary in this case.

This chamge makes the return simply depend on the use of the users
paramater. As soon as this parameter is used, the return will always be:

"user": { "<the user>": { "randompassword": "<the user random password>" } }

In the simply case with one user it will be still

"user": { "randompassword": "<the user random password>" }

Fixes: #1052 (ipauser should consitently return randompasswords when
              used with users)

A temporary krb5 configuration was used to join the domain in
ipaclient_join. After that the final krkb5 configuration was created
with enabled DNS discovery and used for the remainaing tasks, where also
a connection to the IPA API was done.

With several servers the DNS discovery could have picked up a different
server. If the client deployment was faster than the replication this
could have lead to an unknown host error.

The issue was seen in performance testing where many simultaneous client
enrollments have been done..

The goal is to keep server affinity as long as possible within the
deployment process:

The temporary krb5.conf that was used before in ipaclient_join was
pulled out into an own module. The generated temporary krb5.conf is now
used in ipaclient_join and also ipaclient_api.

The generation of the final krb5.conf is moved to the end of the
deployment process.

Same as: https://pagure.io/freeipa/issue/9228

The setup of certmonger has been pulled out of ipaclient_setup_nss and moved
to the end of the process after generating the final krb5.conf as it will
use t will only use /etc/krb5.conf.

Certificate issuance may fail during deployment due to using the final
krb5.conf, but certmonger will re-try the request in this case.

Same as: https://pagure.io/freeipa/issue/9246

Signed-off-by: Denis Karpelevich <dkarpele@redhat.com>