Add support for OpenStack

[cw-kojima1003]

Summary:
This pull request allows cloud-api-adaptor(CAA) to support OpenStack-based clouds.

Background:
There is currently no provider in CAA that supports clouds built with standard OpenStack.
By implementing an OpenStack provider, we can offer secure pod execution environments in a wider range of fields.
As stated in the link below, we are focusing on implementations related to ARM CCA.
This PR provides an architecture-independent implementation.
Moving forward, we aim to execute PeerPods on OpenStack clouds that support ARM CCA.

Links:
This PR is for the purpose and related work described in the following Issue.
#2387

Task:
Adding an built-in Provider for OpenStack, referring to the following documentation.
https://github.com/confidential-containers/cloud-api-adaptor/blob/main/src/cloud-api-adaptor/docs/addnewprovider.md

• Add and initialize the OpenStack provider manager
• Add a definition for the configuration struct
• Add cloud interfaces
• Add provider interfaces
• Add additional files to modularize the code
• Add relevant tests (unit tests and e2e tests)
• Add documentation on how to build a Pod VM image
• Update entrypoint.sh and Makefile

Implemented:
[x] Launch Peer Pod with standard VM
[x] Unit tests and E2E tests
[x] Manual connectivity verification

[cw-kojima1003]

Resubmission:
This PR has been resubmitted. Due to a change in our company's internal policy, the repository was moved from a personal account to this organization.

The original discussion can be found here: #2805.

Changes since #2805:

• Added e2e tests for the OpenStack provider
• Added a README covering CAA deployment on OpenStack, Pod VM creation, and e2e test steps
• Switched deployment to a Helm-based approach and updated compatibility to CAA v0.18 and later (Removed the previous kustomize-based deployment)

[mkulke]

I have only glanced at the code so far (but it looks comprehensive and well documented👍).

I have a couple of abstract questions:

• I noticed in your instructions that you use the packer-based flow to create podvm images. The project has been moving towards podvm images that are built with mkosi (./podvm-mkosi). It has different security characteristics (integrity-protected rootfs, no cloud-init and other hardening measures). Did you test the Openstack provider with mkosi images?

• There is e2e test code in the PR, but I don't see github action workflows that would exercise them. I assume a public github-runner is not big enough to host an OS and a kubernetes deployment. Where do you plan to run those tests?

• I don't see any mention of attestation in the docs, I assume the OS provider is agnostic to the TEE that is being used? Do our current attestation-agent builds support all conceivable TEEs or do we need to adjust that?