new helm chart

[NissesSenap]

Context

Fix: #7016

Description

Creates a new helm chart, that is possible to build on and scale separate deployments individually.
Breaking out secrets from values files and providing documentation around helm.

Checklist

• Are there new checks included in this PR? Yes / No
  • If so, do we need to update permissions for the provider? Please review this carefully.
• Review if the code is being covered by tests.
• Review if code is being documented following this specification https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
• Review if backport is needed.
• Review if is needed to change the Readme.md

API

• Verify if API specs need to be regenerated.
• Check if version updates are required (e.g., specs, Poetry, etc.).
• Ensure new entries are added to CHANGELOG.md, if applicable.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[NissesSenap]

This is an initial draft, but I don't think I will have time to work much more on this in the near feature, but I wanted to upload something. If someone else got time, I would love to see improvements to it.

In the PR there is a TODO that cover most things that I personally think should be solved before merge.
But I don't know if some of the features are supported by the application itself.

Questions

• Does the API/cellery instance got any readiness probes? I can't find any in docker-compose at least.
• What config is needed in the UI frontend compared to the backend? In docker-compose everything is just mounted. Looking at the old helm chart I think I only need to add DJANGO_AUTH_SECRET. But I haven't had time to add the UI to test it out.
• Does the API actually support autoscaling? In the docker entrypoint a DB migration always happens. How good is the migration framework that you are using when it comes to looking the database? What would happen if two new API instances starts relatively at the same time? Will the first on update some SHA to tell the other replica that it already has started the DB migration?

Issue

• The container is massive, 1.92Gb. Could we go over to some multi-stage container build? Does the application need any CLIs of any kind? Or is it just priority/time?
• What I can see it's not possible to any env variable to configure the config file location:

  prowler/prowler/lib/cli/parser.py

  Lines 344 to 353 in 8a144a4

  	def __init_config_parser__(self):
  	config_parser = self.common_providers_parser.add_argument_group("Configuration")
  	config_parser.add_argument(
  	"--config-file",
  	nargs="?",
  	default=default_config_file_path,
  	help="Set configuration file path",
  	)
  	config_parser.add_argument(
  	"--fixer-config",

  
  Would be nice to add this feature, that way we can remove horrible hard-coded paths that depends on the dockerfile.