Add config fallbacks for session, cache and queue when disabling redis-cluster (#585)

### Description of the change

Add config fallbacks for `session`, `cache` and `queue` including tests.

### Benefits

If users disable the default `redis-cluster` sub-chart dependency, this will configure the respective sections to use the Gitea defaults as listed in https://docs.gitea.com/next/administration/config-cheat-sheet.

### Possible drawbacks

Users will run on non-optimal settings for production without knowing their config.

### Applicable issues

  - fixes #584 #573 #489 #476 #468 #453

### Checklist

<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->

- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added

Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/585
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>

README.md

@@ -14,6 +14,7 @@
     - [Server defaults](#server-defaults)
     - [Metrics defaults](#metrics-defaults)
     - [Rootless Defaults](#rootless-defaults)
+    - [Session, Cache and Queue](#session-cache-and-queue)
   - [Single-Pod Configurations](#single-pod-configurations)
   - [Additional _app.ini_ settings](#additional-appini-settings)
     - [User defined environment variables in app.ini](#user-defined-environment-variables-in-appini)
@@ -229,6 +230,16 @@ If `.Values.image.rootless: true`, then the following will occur. In case you us
 
   [see deployment.yaml](./templates/gitea/deployment.yaml) template inside container "env" declarations
 
+#### Session, Cache and Queue
+
+The session, cache and queue settings are set to use the built-in Redis Cluster sub-chart dependency.
+If Redis Cluster is disabled, the chart will fall back to the Gitea defaults which use "memory" for `session` and `cache` and "level" for `queue`.
+
+While these will work and even not cause immediate issues after startup, **they are not recommended for production use**.
+Reasons being that a single pod will take on all the work for `session` and `cache` tasks in its available memory.
+It is likely that the pod will run out of memory or will face substantial memory spikes, depending on the workload.
+External tools such as `redis-cluster` or `memcached` handle these workloads much better.
+
 ### Single-Pod Configurations
 
 If HA is not needed/desired, the following configurations can be used to deploy a single-pod Gitea instance.