Added libpq option target_session_attrs for cluster support

[moonrail]

Since PostgreSQL 10 the C library libpq, that is used by psycopg, that itself is used in Django and therefore AWX, supports specifying multiple PostgreSQL hosts and a kind of selector.

See these links:

• https://www.postgresql.org/docs/14/libpq-connect.html#LIBPQ-CONNSTRING
• https://www.postgresql.org/docs/14/libpq-connect.html#LIBPQ-CONNECT-TARGET-SESSION-ATTRS

Basically one is able to specify multiple hosts and what a session to a host should support.
libpq will then try each host and use first matching one.
In the case of an aborted connection or if a failover happens, the application will still get an error, but is able to retry and a new host will be searched for automatically.

This looks to be supported in AWX.
E.g. the Task Dispatcher retries and therefore uses this feature implicitly: https://github.com/ansible/awx/blob/21.0.0/awx/main/dispatch/worker/base.py#L168
I've tested a PostgreSQL failover while running multiple Jobs in AWX:

• without these settings, e.g. by using a TCP loadbalancer, AWX dispatcher process failed hard and running Jobs failed without clear indication, as to why
• with these settings, all Jobs kept running and AWX was able to recover and in my tests no Job events were lost

The added option in this PR is compatible to single hosts as well.
And it makes sense to set as default, because AWX only supports ReadWrite-connections.

One can use this feature with the awx-operator 0.21.0 even without this PR:

1. create a configmap with e.g. a custom.py, as described in README.md
2. add this line into the custom.py: DATABASES["default"]["OPTIONS"]["target_session_attrs"] = "read-write"
3. add all PostgreSQL hosts seperated by comma to your external PostgreSQL secret, e.g.: host: pgsql1.domain.tld,pgsql2.domain.tld,pgsql3.domain.tld
4. configure both to AWX spec as described in README.md and deploy all definitions

[moonrail]

Umph, sorry about that.
Accidentially pushed changes for #927 to this branch.

[rooftopcellist]

@moonrail Hey, could you rebase this one last time? Sorry for the wait, we are going through old PR's. The change looks good, we just need the rebase.

[moonrail]

@rooftopcellist No worries - I've rebased it.

[moonrail]

As said in #927 I'll not bother anymore if the maintainers have no interest.