test/e2e: re-org the README.md sections

So that "Running tests for PodVM with Authenticated Registry" and
"Running the e2e Test Suite on an Existing CAA Deployment" belong
to "Running end-to-end tests".

"Adding support for a new cloud provider" moved to last section in
the document.

Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>

src/cloud-api-adaptor/test/e2e/README.md

@@ -135,37 +135,6 @@ Use the properties on the table below for Libvirt:
 |vxlan_port| VXLAN port number||
 |cluster_name|Cluster Name| "peer-pods"|
 
-# Adding support for a new cloud provider
-
-In order to add a test pipeline for a new cloud provider, you will need to implement some
-Go interfaces and create a test suite. You will find the reference implementation on the files
-for the *libvirt* provider.
-
-## Create the provision implementation
-
-Create a folder named <CLOUD_PROVIDER> and create a new Go file (.go) named `provision`.go under it (e.g., `libvirt/provision.go`)
-that should be tagged with `//go:build <CLOUD_PROVIDER>`. That file should have the implementation
-of the `CloudProvisioner` interface (see its definition in [provision.go](../provisioner/provision.go)).
-
-Apart from that, it should be added an entry to the `GetCloudProvisioner()` factory function in [provision.go](../provisioner/provision.go).
-
-## Create the test suite
-
-Create another Go file named `<CLOUD_PROVIDER>_test.go` to host the test suite and provider-specific assertions. It is interpreted as any [Go standard testing](https://pkg.go.dev/testing) framework test file, where functions with `func TestXxx(*testing.T)` pattern are tests to be executed.
-
-Likewise the provision file, you should tag the test file with `//go:build <CLOUD_PROVIDER>`.
-
-You can have tests specific for the cloud provider or re-use the existing suite found in
-[common_suite.go](./common_suite.go) (or mix both). In the later cases, you must first implement the `CloudAssert` interface (see its definition in [common.go](./common.go)) because some tests will need to do assertions on the cloud side, so there should provider-specific asserts implementations.
-
-Once you got the assertions done, create the test function which wrap the common suite function. For example, suppose there is a re-usable `DoTestCreateSimplePod` test then you can wrap it in test function like shown below:
-
-```go
-func TestCloudProviderCreateSimplePod(t *testing.T) {
-    assert := MyAssert{}
-    DoTestCreateSimplePod(t, assert)
-}
-```
 ## Running tests for PodVM with Authenticated Registry
 
 For running e2e test cases specifically for checking PodVM with Image from Authenticated Registry, we need to export following two variables
@@ -176,7 +145,7 @@ For running e2e test cases specifically for checking PodVM with Image from Authe
 
 To test local changes the test suite can run without provisioning any infrastructure, CoCo or CAA. Make sure your cluster is configured and available via kubectl. You also might need to set up Cloud Provider-specific API access, since some of tests assert conditions for cloud resources.
 
-## Azure
+### Azure
 
 Fill in `RESOURCE_GROUP` and `AZURE_SUBSCRIPTION_ID` with the values you want to use in your test:
 
@@ -203,7 +172,7 @@ TEST_INSTALL_CAA=no \
 TEST_PROVISION_FILE="${PWD}/skip-provisioning.properties" \
 ```
 
-## IBM Cloud
+### IBM Cloud
 Take region `jp-tok` for example.
 ```
 cd ../.. # go to project root
@@ -231,3 +200,35 @@ EOF
 - For `INSTANCE_PROFILE_NAME`, if it's not secure execution, the value is started with "bz2". If it's secure execution, the value is started with 'bz2e'. More values can be found through ibmcloud command `ibmcloud is instance-profiles`.
 - For `PODVM_IMAGE_ID`, the vpc image id uploaded to ibmcloud.
 - For `CAA_IMAGE_TAG`, the commit id of project. The commit id can be found here: https://github.com/confidential-containers/cloud-api-adaptor/commits/main/
+
+# Adding support for a new cloud provider
+
+In order to add a test pipeline for a new cloud provider, you will need to implement some
+Go interfaces and create a test suite. You will find the reference implementation on the files
+for the *libvirt* provider.
+
+## Create the provision implementation
+
+Create a folder named <CLOUD_PROVIDER> and create a new Go file (.go) named `provision`.go under it (e.g., `libvirt/provision.go`)
+that should be tagged with `//go:build <CLOUD_PROVIDER>`. That file should have the implementation
+of the `CloudProvisioner` interface (see its definition in [provision.go](../provisioner/provision.go)).
+
+Apart from that, it should be added an entry to the `GetCloudProvisioner()` factory function in [provision.go](../provisioner/provision.go).
+
+## Create the test suite
+
+Create another Go file named `<CLOUD_PROVIDER>_test.go` to host the test suite and provider-specific assertions. It is interpreted as any [Go standard testing](https://pkg.go.dev/testing) framework test file, where functions with `func TestXxx(*testing.T)` pattern are tests to be executed.
+
+Likewise the provision file, you should tag the test file with `//go:build <CLOUD_PROVIDER>`.
+
+You can have tests specific for the cloud provider or re-use the existing suite found in
+[common_suite.go](./common_suite.go) (or mix both). In the later cases, you must first implement the `CloudAssert` interface (see its definition in [common.go](./common.go)) because some tests will need to do assertions on the cloud side, so there should provider-specific asserts implementations.
+
+Once you got the assertions done, create the test function which wrap the common suite function. For example, suppose there is a re-usable `DoTestCreateSimplePod` test then you can wrap it in test function like shown below:
+
+```go
+func TestCloudProviderCreateSimplePod(t *testing.T) {
+    assert := MyAssert{}
+    DoTestCreateSimplePod(t, assert)
+}
+```