giseldo/neodataset huggingface dataset:
View Script button text and icon on Cluster Configuration tab have different behaviours

### Summary
When trying to view the Managed SQL Script within the SGCluster Configuration tab, the button text (`View Script`) and the eye icon behave in different ways:
- `View Script` opens a pop-up containing the Script.
- The eye icon opens a pop-up containing the text `undefined`.

**Note:** Although this issue was spotted on the `View Script` button, we need to make sure it does not happen on other buttons as well.

#### Steps to reproduce
1. Create a Cluser.
2. Go to the Configuration tab. Scroll to Managed SQL section and click on `View Entries`. A pop-up with the Script Entries will appear.
4. Click on the `View Script` text. A pop-up containing the Script will appear.
5. Close the Script pop-up and click on the eye icon next to the `View Script` text. A pop-up with the text `undefined` will appear.

### Expected Behaviour
Both the text and the eye icon of the button should behave in the same way and open the Script pop-up.

### Environment
- StackGres version: 1\.4.0

### Relevant logs and/or screenshots
![image](https://gitlab.com/ongresinc/stackgres/uploads/674bbb18beea6f1f9325b1aa222de97e/image.png)

Story points: 4.0
notValid class not being removed on Babelfish Experimental Feature

### Summary 
`notValid` class is not being removed on `Babelfish Experimental Feature` field.

**Note:** Although this issue was spotted on the `Babelfish Experimental Feature` field, we need to make sure it does not happen on other fields as well.

#### Steps to reproduce
1. Go to Cluster Creation form.
2. Give the cluster a name. Select Babelfish flavor but do not enable `Babelfish Experimental Feature (required)`.
3. Click on `View Summary`.
4. The Summary won't open because not all required fields are filled in. The unfilled required inputs and the Step containing them now have a `notValid` class and appear in red.
5. Enable `Babelfish Experimental Feature (required)`.
6. The class `notValid` remains, though the Summary now opens. 

### Expected Behaviour
Once `Babelfish Experimental Feature (required)` is enabled, `notValid` class should be removed.

### Environment
- StackGres version: 1\.4.0

### Relevant logs and/or screenshots
![Screen_Recording_2023-01-09_at_17.31.53](/uploads/32b204610965b9239409fc5c5e49face/Screen_Recording_2023-01-09_at_17.31.53.mov)

Story points: 8.0
Service Account JSON not shown on Summary

### Summary
Service Account JSON is not shown on the Summary on Object Storage Creation form (Google Cloud Storage).

#### Steps to reproduce
1. Go to Object Storage Creation form.
2. Select Google Cloud Storage.
3. Fill in all required fields, including the `Service Account JSON`.
4. Click con `View Summary`.
5. The file name and contents do not appear on the Summary.

### Expected Behaviour
Service Account JSON name should be shown on Object Storage Summary.

### Environment
- StackGres version: 1\.4.0

Story points: 4.0
Continue on SGScripts Error should not be visible if there are no Scripts set

### Summary
On Cluster Creation form, Scripts step, the field `Continue on SGScripts Error` is placed at the very top. `Continue on SGScripts Error` depends on the existence of Scripts, and enabling/disabling it will have no impact if no Scripts are set. Even though `Continue on SGScripts Error` depends on Scripts existence, it is always visible at the top and the User can enable/disable it (with no effects).

### Expected Behaviour
If enabling/disabling `Continue on SGScripts Error` won't have any effects unless there are Scripts set, `Continue on SGScripts Error` field should not appear unless there are Scripts set. Also, since it depends on Scripts being set, it should appear _after_ the Scripts fieldset. 

Also, on the Cluster tab, the value for `Continue on SGScripts Error` does not appear.

### Environment
- StackGres version: 1\.4.0

Story points: 4.0
Summaries should not open unless all required fields are filled in

### Summary
On all Creation forms through the Web UI, Summaries can only be opened when all required fields are filled in. This does not happen for Storage Type (SGObjectStorage form) and Database Operation (SGDbOps form) fields, both of them required.

### Current Behaviour 
The User can open the Summary without selecting a Storage Type (required) or Database Operation (required).

#### Steps to reproduce
1. Go to Object Storage Creation form. 
2. Give the configuration a name.
3. Do not select any Storage Types (required).
4. Click on `View Summary`.
5. The Summary will open even though no Storage Type (required) was set.

### Expected Behaviour
- Object Storage Summary should not open unless a Storage Type (required) is selected.
- DbOp Summary should not open unless a Database Operation (required) is selected.

### Environment
- StackGres version: 1\.4.0

Story points: 8.0
Disable Connection Pooling not working properly on Cluster Form

### Summary
On the Cluster Creation form, Connection Pooling Configuration is set even if Connection Pooling is disabled.

#### Steps to reproduce
1. Go to Create Cluster form. 
2. Select a Connection Pooling Configuration.
3. Disabled Connection Pooling.
4. The input for Connection Pooling Configuration still appears (disabled) and shows the selected Connection Pooling Configuration.
5. Create the Cluster.
6. On the Configuration tab it is shown that the Cluster has a Connection Pooling Configuration.

**Note**: if no Connection Pooling Configuration is selected, a default Connection Pooling Configuration is created even if Connection Pooling is disabled.

### Expected Behaviour
If Connection Pooling is disabled:
- The Connection Pooling Configuration field should not be shown.
- No Connection Pooling Configuration should be set or created when creating the Cluster.

### Environment
- StackGres version: 1\.4.0

### Relevant logs and/or screenshots
**Cluster Creation form. Connection Pooling is disabled, but the selected configuration `test` still appears:**
![Screenshot_2023-01-09_at_11.07.06](/uploads/ae0a70fe23531087dae34887e4c7f0d8/Screenshot_2023-01-09_at_11.07.06.png)

**Cluster Configuration tab. Even though Connection Pooling was disabled, the configuration `test` appears:**
![Screenshot_2023-01-09_at_11.07.49](/uploads/005f264d71b18957a3f151520b75621c/Screenshot_2023-01-09_at_11.07.49.png)

Story points: 8.0
Script Source on Create Cluster form not working

### Summary
When trying to select a Script Source on the Create Cluster form, the select is not working. No errors appear on the Console.

#### Steps to reproduce
1. Go to Create Cluster.
2. Try to select a Source on the Scripts step.

### Expected Behaviour
The Script Source should load.


### Environment
- StackGres version: 1\.4.0


### Relevant logs and/or screenshots
![Screen_Recording_2023-01-09_at_10.33.44](/uploads/4d5e3480d94854388b93830230a227b1/Screen_Recording_2023-01-09_at_10.33.44.mov)

Story points: 8.0
Object Storage selector on Cluster form shows all Object Storages from all Namespaces

### Summary
When selecting an Object Storage on the Create Cluster form, the dropdown displays all Object Storages from all Namespaces. If the selected Object Storage is from a different Namespace, the Cluster creation will fail.

#### Steps to reproduce
1. Create Object Storages on different Namespaces.
2. Go to Create Cluster, Backups step. Select an Object Storage.
3. The dropdown shows a list of all Object Storages from all Namespaces.

### Expected Behaviour
Only Object Storages from the Namespace the User is on should be shown.

### Possible Solution
Object Storages should be filtered by Namespace on the Create Cluster form.

### Environment
- StackGres version: 1\.4.0

Story points: 4.0
Minimized sidebar namespaces list is open when tab is reloaded

On the web console, when the sidebar is minimized, a cookie is set for the browser to remember user's preference. 

When the browser tab is reloaded, even though the sidebar appears minimized, the namespaces list is always shown floating next to the sidebar and it hides only when passing the mouse hover it.

![image](/uploads/47dc537c89eb724ba15108f4aaee7e12/image.png)

Story points: 4.0
Web console sidebar items hidden behind dialog popups

### Summary

On the web console, when a dialog box is shown on the main container, even though users can interact with the sidebar, its nav items are hidden behind the dialog box.

![image](/uploads/6c0f0dc410434ead96a82e94a9c7ccec/image.png)


#### Steps to reproduce

- Enter the web console
- Edit any resource
- Click on "View Summary" (a dialog box will open)
- Interact with sidebar items
- Links to access resources will be hidden behind the dialog box


### Expected Behaviour

Whenever interaction with the sidebar items is possible, they must be on top of any other content available.


### Environment

- StackGres version: `1.4.0`

Story points: 1.0
Implement the UI for containers, initContainers and requests for SGInstanceProfile

The objective of this issue is to create the necessary requirements for the UI to support containers, initContainers and requests for SGInstanceProfile.

Based on the development of the issue: #144 and #820

**Acceptance criteria:**

* [ ] Implement the UI for containers, initContainers and requests for SGInstanceProfile
* [ ] Test the implementation by setting value for containers, initContainers and resources section.

Story points: 2.0
Cluster is not reconciled when prometheus auto bind is disabled in the operator

### Summary

Cluster is not reconciled when prometheus auto bind is disabled in the operator

### Current Behaviour 

The cluster is not created and the operator logs the following exception:

```java
Cluster reconciliation cycle failed: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"servicemonitors.monitoring.coreos.com is forbidden: User \"system:serviceaccount:stackgres:stackgres-operator\" cannot list resource \"servicemonitors\" in API group \"monitoring.coreos.com\" in the namespace \"keycloak\"","reason":"Forbidden","details":{"group":"monitoring.coreos.com","kind":"servicemonitors"},"code":403}
```

#### Steps to reproduce

1. Install the operator with `--set prometheus.allowAutobind=false`
2. Create a SGCluster

The test may require the prometheus CRDs to be installed

### Expected Behaviour

The cluster is created and no exception is logged.

### Possible Solution

Skip scanning of prometheus CRs in the reconciliation cycle when the promethues auto bind is disabled.

### Environment

- StackGres version: 1.3.3
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 2.0
Backup are marked completed when they are not

### Summary

Backup are marked completed when they are not.

### Current Behaviour 

The backup has the `Completed` status but no information about the backup name and other related properties are present:

```yaml
apiVersion: stackgres.io/v1
kind: SGBackup
status:
  backupPath: sgbackups.stackgres.io/test/test/14
  process:
    jobPod: bk2022-10-17-17-10-58-backup-8542j
    status: Completed
  sgBackupConfig:
    baseBackups:
      compression: lz4
    storage:
      s3Compatible:
        awsCredentials:
          secretKeySelectors:
            accessKeyId:
              key: accessKey
              name: test-backup-credentials
            secretAccessKey:
              key: secretKey
              name: test-backup-credentials
        bucket: 4amlunch-db-backups
        enablePathStyleAddressing: true
        endpoint: https://minio
        region: k8s
      type: s3Compatible
```

#### Steps to reproduce

1. Create a SGCluster with backup configuration
2. Create a SGBackup
3. While the backup is running and is executing the remote backup with wal-g change StackGres operator deployment to have 0 replicas
4. Wait for the Job to complete
5. Change StackGres operator deployment to have 1 replicas

### Expected Behaviour

The backup has the `Completed` status and all the information about the backup name and other related properties must be present.

### Environment

- StackGres version: 1.3.2 (but probably this affects also previous versions)
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 2.0
setup-data-path.sh not executing, resulting in broken permissions


### Summary

In v1.3.2 there is a script, that can't be executed before the postgresql instance starts: `/etc/patroni/setup-data-path.sh`. This script seems to set some folder permissions for the postgresql data.

I believe this is related to #2052.

### Current Behaviour 

There's an error logged before the postgresql instance is started:
```
2022-10-18 04:58:35,278 ERROR: Failed to execute ['/etc/patroni/setup-data-path.sh', 'on_start', 'replica', 'clustername']
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/patroni/postgresql/cancellable.py", line 30, in _start_process
    self._process = psutil.Popen(cmd, *args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/psutil/__init__.py", line 1316, in __init__
    self.__subproc = subprocess.Popen(*args, **kwargs)
  File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/etc/patroni/setup-data-path.sh'
```

This script sets some permissions on the postgresql data folder. Because it's not executed the permissions for the folder aren't correct, and postgresql refuses to start. Manually executing the script is working.

#### Steps to reproduce

1. Update operator to v1.3.2
2. restart a cluster
3. The nodes fail to restart due to the broken permissions

Note: downgrading to v1.3.1 resolves the issue.

### Expected Behaviour

The script can be run so that the permissions are set correctly.

### Possible Solution

The script is currently missing a shebang. It might be enough to specify it. Otherwise, call it explicitly with something like `sh /etc/patroni/setup-data-path.sh`.

### Environment

- StackGres version: 1.3.2
- Kubernetes version: 1.24
- Cloud provider or hardware configuration: Ceph CSI RBD


### Relevant logs and/or screenshots

```
2022-10-18 04:58:35,278 ERROR: Failed to execute ['/etc/patroni/setup-data-path.sh', 'on_start', 'replica', 'earthnet']
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/patroni/postgresql/cancellable.py", line 30, in _start_process
    self._process = psutil.Popen(cmd, *args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/psutil/__init__.py", line 1316, in __init__
    self.__subproc = subprocess.Popen(*args, **kwargs)
  File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/etc/patroni/setup-data-path.sh'
```

Story points: 2.0
Babelfish compass throws error on the web console

### Summary

When using the Babelfish Compass feature on the web console, the request made to the REST API is missing a trailing slash, which causes the request to return a `404 Not Found` code.

#### Steps to reproduce

- Enter the web console
- Select any namespace
- On the sidebar, click on `Applications > babelfish-compass`
- Enter any report name + file
- Click on SEND

The request will return an error and a `404 not found` code can be seen on the browser's console.


### Expected Behaviour

Requests made to babelfish-compass should point to the correct endpoint `/applications/com.ongres/babelfish-compass`

### Possible Solution

Include the trailing slash at the beginning of the endpoint request.



### Environment

- StackGres version: `1.3.1`

Story points: 2.0
Containers others than patroni should only set requests resource requirements

Implementation of #144 introduced a lot of problems due to default resource limits being enforced to be too low for the correct functioning of the StackGres ecosystem. In particular container where OOMKilled for SGBackups, SGDbOps and other sidecars.

To make this change compatible we will also include boolean field `.spec.pods.resources.enableClusterLimitsRequirements` that will allow to enforce resource limits for containers other than patroni as specified in the reference SGInstanceProfile of the SGCluster.

## Acceptance Criteria

* [ ] Implement the change
* [ ] Test the change
* [ ] Documentation

Story points: 2.0
Old SGBackup, SGDbOps, SGScript and SGDistributedLogs throws exception about invalid version

### Summary

Some StackGres custom resources throw an exception when the operator is upgraded and do not support old version any more.

### Current Behaviour 

Whenever an SGBackup, SGDbOps, SGScript, SGDistributedLogs are annotated with an unsupported StackGres version the operator show the following error stack trace:

```
2022-10-06 08:39:19,098 ERROR [io.st.op.conciliation] (SGBackup-ReconciliationLoop) Reconciliation of SGBackup default/test failed: java.lang.IllegalArgumentException: Invalid version 1.0.0
at io.stackgres.common.StackGresVersion.lambda$ofVersion$1(StackGresVersion.java:90)
...
```

And the resource is not reconcilied.

#### Steps to reproduce

1. Install StackGres Operator 1.0.0
2. Install MinIO
3. Create an SGBackupConfig targeting MinIO
4. Create an SGCluster with backups referencing the created SGObjectStorage
5. Create an SGBackup
6. Upgrade to StackGres Operator 1.2.0
7. Perform an SGDbOps secutiry upgrade of the cluster SGCluster
8. Upgrade to StackGres Operator 1.3.1

### Expected Behaviour

The SGBackup reconciliation cycle should not throw any exception and reconcile it correctly.

### Possible Solution

Reconcile old versions of some StackGres custom resources.

### Environment

- StackGres version: 1.3.1
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 2.0
Support podAffinity and podAntiAffinity for SGCluster

### Problem to solve

Support [`podAffinity` and `podAntiFinity`](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) in the `SGCluster` custom resource.

### Proposal

Proposed section to map to `.spec.template.spec.affinity.podAffinity` and `.spec.template.spec.affinity.podAntiAffinity` section of generated `StatefulSet`:

```yaml
apiVersion: stackgres.io/v1
kind: SGCluster
spec:
  pods:
    scheduling:
      podAffinity: [ <object> ] # the same as https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podaffinity-v1-core
      podAntiAffinity: [ <object> ] # the same as https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podantiaffinity-v1-core
```

## Acceptance Criteria

* [ ] Implement the change in the SGCluster CRD
* [ ] Implement the change in the REST API
* [ ] Tests
* [ ] Documentation

### Links / references

* https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podaffinity-v1-core
* https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podantiaffinity-v1-core

Story points: 8.0
Support PostgreSQL v15.0

The goal of this issue is to support PostgreSQL v15.0 in StackGres 

Released on October 13: https://www.postgresql.org/about/news/postgresql-15-released-2526/

Release notes: https://www.postgresql.org/docs/15/release-15.html


**Acceptance criteria:**

- [ ]  Test and add the support for PG 15

Story points: 2.0
The fields in section .spec.nonProductionOptions are reset by the Web Console

### Summary

After updating (without changing anything) an SGCluster custom resource the fields in section `.spec.nonProductionOptions` other than `.spec.nonProductionOptions.disableClusterPodAntiAffinity` are removed by the Web Console 

### Current Behaviour

If we have a `.spec.nonProductionOptions` like the following:

```yaml
disableClusterPodAntiAffinity : true
disableClusterResourceRequirements: true
disablePatorniResourceRequirements: false
```

After an update without changing any field the section is updated as follow:

```yaml
disableClusterResourceRequirements: true
disablePatorniResourceRequirements: false
```

#### Steps to reproduce

1. Create an SGCluster setting `.spec.nonProductionOptions.disableClusterResourceRequirements` to `true`
2. Update the SGCluster without changing any field from the Web Console

### Expected Behaviour

After an update without changing any field the section `.spec.nonProductionOptions` is not changed.

### Environment

- StackGres version: 1.3.1
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 16.0
Increase memory limit for prometheus-postgres-exporter container to 256Mi

We saw that the current minimum size of 64Mi for prometheus-postgres-exporter container memory limit is not enough in some real life usage scenario. The amount of memory measured for such container reached a maximum of 107Mi. We should increase the default memory limit to 256Mi for prometheus-postgres-exporter in order to prevent OOM in more cases. This does not means that users will have to increase it in some edge cases. 

## Implementation plan

Set memory limit to 256Mi for container prometheus-postgres-exporter in class `io.stackgres.common.StackGresContainer`.

## Acceptance Criteria

* [ ] Implement the solution
* [ ] Test the implementation

Story points: 2.0
Make major version upgrade check avoid apply any change and revert the cluster back to previous version

The check flag is not really useful since an user may want to know before performing the actual major version upgrade to know if preliminary checks will pass.

Make major version upgrade check avoid apply any change and revert the cluster back to previous version after the operation completes

## Implementation plan

Use the same rollback operation implemented in #1983 to always rollback the operation after the check is successful.

## Acceptance Criteria

* [ ] Implement the feature
* [ ] Tests

Story points: 4.0
Improve major version upgrade copy missing files with cp

Current mechanism to copy missing files from old lib64 folder in order to make them available to `pg_upgrade` command during major version upgrade SGDbOps operation is slow since it uses a custom method with recursive shell functions. Try to replace it using a more performant method.

## Implementation plan

The command `cp -auv` can be used as a replacement for this operation.

## Acceptance Criteria

* [ ] Refactor the copy of missing file method
* [ ] Pass the current dbops-major-version-upgrade* E2E tests

Story points: 2.0
Kubernetes Client throws UnrecognizedPropertyException after upgrading the operator when a new field is added to any CRD

Kubernetes Client throws `UnrecognizedPropertyException` after upgrading the operator when a new field is added to any CRD. This happens whenever the field is filled in any CR making the old version of the local pod controller to fail.

## Implementation plan

Make the Kubernetes Client use the `ObjectMapper` configured by Quarkus

## Acceptance Criteria

* [ ] Add a specific check in the dbops-secutiry-upgrade E2E test to make sure no `UnrecognizedPropertyException` error appear after an upgrade
* [ ] Solve the issue in the code

Story points: 4.0
Support Kubernetes 1.25

Release info: 
* https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/

Updated Kind 0.15.0
* https://github.com/kubernetes-sigs/kind/releases/tag/v0.15.0

**Acceptance criteria:**
- [ ] Update Kind to 0.15.0
- [ ] Update Helm chart
- [ ] Test K8s 1.25

Story points: 1.0