docs: restore Galera cluster deployment documentation (#1324)

Restore the Galera deployment option to MariaDB documentation.
The Galera kustomization configuration was already present in the
repository but the documentation was previously removed. This adds
back the Galera deployment option alongside the existing Replication
and AIO configurations.

Author: aedan

docs/infrastructure-mariadb.md

@@ -53,6 +53,14 @@ kubectl --namespace mariadb-system get pods -w
     kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/overlay
     ```
 
+=== "Galera"
+
+    MariaDB with Galera Cluster is a popular choice for ensuring high availability and scalability in OpenStack deployments. Galera is a synchronous multi-master replication plugin for MariaDB, allowing all nodes in the cluster to read and write simultaneously while ensuring data consistency across the entire cluster. This setup is particularly advantageous in OpenStack environments, where database operations must be highly reliable and available to support the various services that depend on them. By using Galera with MariaDB, OpenStack deployments can achieve near-instantaneous replication across multiple nodes, enhancing fault tolerance and providing a robust solution for handling the high-demand workloads typical in cloud environments.
+
+    ``` shell
+    kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/galera
+    ```
+
 === "AIO"
 
     In some OpenStack deployments, a single MariaDB server is used to manage the database needs of the cloud environment. While this setup is simpler and easier to manage than clustered solutions, it is typically suited for smaller environments or use cases where high availability and fault tolerance are not critical. A single MariaDB server provides a centralized database service for storing and managing the operational data of OpenStack components, ensuring consistent performance and straightforward management. However, it is important to recognize that this configuration presents a single point of failure, making it less resilient to outages or hardware failures compared to more robust, multi-node setups.