[WIP] Grant 'superuser' to the members of Postgres admin teams (#371)

Added support for superuser team in addition to the admin team that owns the postgres cluster.

docs/administrator.md

@@ -208,3 +208,15 @@ generated from the current cluster manifest. There are two types of scans: a
 `sync scan`, running every `resync_period` seconds for every cluster, and the
 `repair scan`, coming every `repair_period` only for those clusters that didn't
 report success as a result of the last operation applied to them.
+
+## Postgres roles supported by the operator
+
+The operator is capable of maintaining roles of multiple kinds within a Postgres database cluster:
+
+1. **System roles** are roles necessary for the proper work of Postgres itself such as a replication role or the initial superuser role. The operator delegates creating such roles to Patroni and only establishes relevant secrets.
+
+2. **Infrastructure roles** are roles for processes originating from external systems, e.g. monitoring robots. The operator creates such roles in all PG clusters it manages assuming k8s secrets with the relevant credentials exist beforehand.
+
+3. **Per-cluster robot users** are also roles for processes originating from external systems but defined for an individual Postgres cluster in its manifest. A typical example is a role for connections from an application that uses the database.
+
+4. **Human users** originate from the Teams API that returns list of the team members given a team id. Operator differentiates between (a) product teams that own a particular Postgres cluster and are granted admin rights to maintain it, and (b) Postgres superuser teams that get the superuser access to all PG databases running in a k8s cluster for the purposes of maintaining and troubleshooting.

docs/reference/operator_parameters.md

@@ -377,6 +377,9 @@ key.
   List of roles that cannot be overwritten by an application, team or
   infrastructure role. The default is `admin`.
 
+* **postgres_superuser_teams**
+  List of teams which members need the superuser role in each PG database cluster to administer Postgres and maintain infrastructure built around it. The default is `postgres_superuser`.
+
 ## Logging and REST API
 
 Parameters affecting logging and REST API listener. In the CRD-based configuration they are grouped under the `logging_rest_api` key.