Refactor CDR and CIS workflows

[gurevichdmitry]

Summary of your changes

This PR introduces the capability to install the CDR infrastructure with or without the CIS infrastructure. This enhancement allows for more flexibility in setting up the infrastructure based on the specific needs of the deployment.

Key Changes:

• Added support for installing CDR independently or in combination with CIS.
• Adjusted configuration options to ensure seamless integration between CDR and CIS when both are enabled.

Screenshot/Data

Related Issues

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary README/documentation (if appropriate)

Introducing a new rule?

• Generate rule metadata using this script
• Add relevant unit tests
• Generate relevant rule templates using this script, and open a PR in elastic/packages/cloud_security_posture

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b dg-refactor-cloud-logs-wf upstream/dg-refactor-cloud-logs-wf
git merge upstream/main
git push upstream dg-refactor-cloud-logs-wf

[mergify]

This pull request does not have a backport label. Could you fix it @gurevichdmitry? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit
  NOTE: backport-v8.x has been added to help with the transition to the new branch 8.x.

[gurevichdmitry]

Workflow runs:

• CDR successful execution
• CIS successful execution
• CDR and CIS successful execution
• Destroy environment execution

[orouz]

it looks like each workflow - cdr infra or create environment can run either infra or both. personally i think a single workflow with 2 checkboxes would be simpler, but maybe i'm missing smth

[orouz]

maybe a boolean for CDR and CIS is better? otherwise the string needs to be known to whoever runs this workflow

[orouz]

consider splitting this workflow to multiple actions, like deploy-elk, deploy-cdr, deploy-cis and using whichever is required based on inputs.

i think doing so will make the workflow more approachable for future updates as it is getting a bit complex. it'll also remove the need of various wrapper script like manage_infrastructure.sh and set_cloud_env_params.sh