* Zabbix server now always has "HA Cluster" mode set to "on", making it
  possible to easily raise replicaCount and have multiple redundant
  server containers
* added cronjob to autoclean orphaned HA nodes (pods being restarted by
  K8S...)
* easy-to-use Pod anti affinity to make instances of Zabbix Server,
  Zabbix web frontend run on different cluster nodes if possible
* converted zabbix server from statefulset to deployment
* switched from Apache container to Nginx container for web frontend by
  default
* added ZBX_SERVER_NAME as an explicit value, not to have to remember to
  add the according env variable manually as a extraEnv

* Deployment with configurable replicaCount
* automatic configuration of Zabbix Server accordingly
* pod anti affinity to spread multiple instances of cluster nodes if
  possible and replicaCount >1

When starting more than one Zabbix server containers with valid DB
connection credentials at the same time on an empty database, all of
them would try to connect and install the Zabbix DB schema to it at the
same time, leading to errors and invalid queries.

This commit implements an init container on the Zabbix Server pods that
not only waits for the DB to be accessible IP-wise, but also for the
schema to be available. This practically deactivates the schema
auto-creation for the Zabbix Server pods.

At the same time, a one-time Job has been added, which uses the Zabbix
Server image with a slightly modified docker-entrypoint.sh in order to
only wait for DB connection and then to install Zabbix DB schema, but
not to prepare config nor start Zabbix server.

With the combination of these two, we can now start off with a multinode
Zabbix HA cluster in Kubernetes.

if the step to create the db schema takes too long, the wait-job that
should prevent the Zabbix server container to start unless the database
is "really" ready, is leaving off too early and Zabbix server crashes at
start. This commit prevents this error by adding an additional step to
only start the Zabbix server container if there are more than 0 users in
the users table.

- certificate secret
- frontend settings example (via env)

We shouldn avoid exposing any part of the application by accident/default

From now on, all settings related to database access credentials are
being managed centrally for the entire chart:

- either by using a "unified_db_secret" containing ALL aspects of the db
  access configuration, conforming to the format being used by the PGO
  Postgres operator,
- explicit settings in the "db_access" section of the values.yaml. In
  case these are used, it is possible to use a secret just and only for
  the DB password, which will then be used by all components that apply.

This commit removes all postgres related username/password and DB name
settings on the levels of each of the components of the chart, and only
keeps the central ones.

instead, there is now an example placed in the values.yaml that shows
how to configure the ZBX_SERVER_NAME for the frontend by using
additional env variables.

new version is 3.0.0

but still, special env var names are needed for the "cleanup" cron job

with this commit it is now possible to add additional (sidecar)
containers and volumes to each of the components if necessary.

For example, this might be needed if an additional utility would have to
run alongside Zabbix Server to pick up "real time export" data and send
them to a message bus or a logging sidecar container that needs to catch
the logs from the main container into an emptyDir volume and ship them
to a central logging system

with this change, it is now possible to supply arbitrary runtime
parameters to the postgresql database.

The "max_connections" setting that was formerly a setting of its own
inside values.yaml has been moved to use this new structure