1. Rely on a single tag ‹with_kv_database› for deciding whether it
   should be deployed or not.
2. Introduce a new variable ‹kv_database› that holds the name of the KV
   database that might be deployed.
   - Also allows for easier deduction of the hostname and makes sure
     that there's always at least one deployment of any kind, i.e., it
     is now not possible to require it present, but have incorrect
     combination of flags, e.g., neither ‹with_redis› nor ‹with_redict›
     set.
3. Add it to templates where it's been forgotten.

Signed-off-by: Matej Focko <[email protected]>

Signed-off-by: Matej Focko <[email protected]>

The leaks in short-running pods result in idle connections
to Redict/Valkey, all of these KV-databases have ‹timeout› option in
their config that allows for iterative cleanup of hanging connections.

This mitigates the issue to the point of still having free connections
slots to Redict/Valkey, i.e., the pods shall be killed, but handlers do
not end up in a retry-loop trying to connect to Redict/Valkey.

Since the config is 1:1 between all Redis, Redict, and Valkey, create
one ConfigMap, map the config into the databases and pass the path
to the config as an argument.

Tested with Redict and Valkey. »NOT« tested with Redis.

Related to packit/packit-service#2522

Signed-off-by: Matej Focko <[email protected]>

- Remove tags for redis and redict, they would not be very helpful,
  since the specific implementation of KV-DB is taken from the variables
  anyways
- Add missing Valkey to the deploymentconfigs
- Add comment with options to the deployment templates

Co-authored-by: Maja Massarini <[email protected]>
Signed-off-by: Matej Focko <[email protected]>