Unify use of pulp_content_bind and pulp_api_bind

[Spredzy]

In its current state, the installer relies on pulp_content_bind and
pulp_api_bind for the following roles: pulp and pulp_content.
Yet, for pulp_webserver it relies on a new set of parameters for the
exact same purposes (note: those parameters are only used in this role);
namely: pulp_content_host, pulp_content_port, pulp_api_host and
pulp_api_port.

While it would be less error prone to follow the 'define it once use
it everywhere pattern', the following PR also allows has the benefit
of:

• Enabling the use of Unix Domain Socket (UDS) to improve scale
  (ie. /var/run/pulpcore-api/pulpcore-api.sock) and apply best
  practice (if you only deal with localhost you don't need to get
  the network stack involved)

• Pave the way for a better IPv6 integration. 127.0.0.1 doesn't
  exist in IPv6 only servers. By using UDS as previously mentionned
  this limitation becomes void for those two (api and content)
  components

fixes #6921

[pulpbot]

Attached issue: https://pulp.plan.io/issues/6921

[Spredzy]

This PR has been successfully tested with the following two scenarios. The design make it so it should be transparent for current user/deployments while allowing one to specify UDS.

Scenario 1: Using Unix Domain Soocket

- hosts: localhost
  vars:
    pulp_settings:
      secret_key: secret
      content_origin: "http://{{ ansible_fqdn }}"
      x_pulp_api_host: 127.0.0.1
      x_pulp_api_port: 80
      x_pulp_api_user: "admin"
      x_pulp_api_password: "{{ pulp_default_admin_password }}"
      x_pulp_api_prefix: "pulp_ansible/galaxy/automation-hub/api"
      galaxy_require_content_approval: "False"
    pulp_default_admin_password: password
    pulp_install_plugins:
      pulp-ansible: {}
      galaxy-ng: {}
      pulp-container: {}
    pulp_api_workers: 4
    pulp_api_bind: 'unix:/var/run/pulpcore-api/pulpcore-api.sock'
    pulp_content_bind: 'unix:/var/run/pulpcore-content/pulpcore-content.sock'
  roles:
    - pulp_database
    - pulp_workers
    - pulp_resource_manager
    - pulp_webserver
    - pulp_content
  environment:
    DJANGO_SETTINGS_MODULE: pulpcore.app.settings

- hosts: localhost
  roles:
    - role: chouseknecht.ansible_galaxy_config
      vars:
        pulp_api_port: 80

Scenario 2: Current implementation binding to 127.0.0.1

- hosts: localhost
  vars:
    pulp_settings:
      secret_key: secret
      content_origin: "http://{{ ansible_fqdn }}"
      x_pulp_api_host: "{{ pulp_api_host }}"
      x_pulp_api_port: "{{ pulp_api_port }}"
      x_pulp_api_user: "admin"
      x_pulp_api_password: "{{ pulp_default_admin_password }}"
      x_pulp_api_prefix: "pulp_ansible/galaxy/automation-hub/api"
      galaxy_require_content_approval: "False"
    pulp_default_admin_password: password
    pulp_install_plugins:
      pulp-ansible: {}
      galaxy-ng: {}
      pulp-container: {}
    pulp_api_workers: 4
  roles:
    - pulp_database
    - pulp_workers
    - pulp_resource_manager
    - pulp_webserver
    - pulp_content
    - chouseknecht.ansible_galaxy_config
  environment:
    DJANGO_SETTINGS_MODULE: pulpcore.app.settings

Note: I am not aware of the upgrade (if any) and the variable deprecation (if any) process. My change hence might not be compatible with those said processes. Please let me know if there is any doc I can check to update my PR accordingly.

[fao89]

LGTM!
Thank you for your explanation and tests, your PRs are awesome!

[bmbouter]

Before merging I want to finalize the discussion on the ticket.

[bmbouter]

We do not need to carry the [deprecated] fields. Can those please be removed?

Also for any vars that are removed, can you add a 6921.removal changelog (separate from the feature changelog). This will clearly call that out as a breaking change for users.

Also can changelogs be line wrapped to 100 chars. Sorry the CI doesn't let you know this. It's part of the Pulp community style guide, but it should also be more clear for contributors on individual repos.

[bmbouter]

Can you also add a CHANGES/6921.removal file that has a changelog entry indicating which variables are removed and what users should use instead?

[bmbouter]

This looks great. Thanks @Spredzy !