Allow to create multiple cloud service providers in the same account and the same region

@yas, I reviewed the patch, and while it looks good and works great for adding the same region multiple times in the system, I have two concerns.

1. Keeping the region in sync. For example, if I have two us-west-2 regions of the same account id (Region A and Region B) defined in the system, and I perform a shutdown or terminate to an instance in Region A. Region A will show the instance as shutdown/terminated. In Region B, the same instance will keep whatever state it has because that region hasn't been updated. This might cause some confusion if the user does not know the system won't update both regions.
2. I grepped the codebase and found that some of the queries do not use the cloud_context in them. This *might* cause some issues because the entities might be in different states because of point #1 above.

Here are the files and its details

Files that contains loadByProperties where cloud_context isn't passed into the query.

• ElasticIpAssociateForm.php
• ElasticIpDisassociateForm.php -
• InstanceAssociateElasticIpForm.php
• InstanceEditForm.php
• SecurityGroupEditForm.php
• VolumeAttachForm.php
• VolumeDetachForm.php
• AwsCloudServerTemplatePlugin.php
• Ec2Service.php

For example, in ElasticIpAssociateForm.php

        $network_interface = $this->entityTypeManager
          ->getStorage("{$module_name}_network_interface")
          ->loadByProperties(['id' => $network_interface_id]);

The following files contains queries using ->getQuery() where cloud_context isn't passed into the query.

• aws_cloud.module
• ElasticIpAssociateForm.php
• InstanceAssociateElasticIpForm.php
• InstanceEditForm.php

For example, in aws_cloud.module

function aws_cloud_get_available_elastic_ips($cloud_context) {
  $entity_type_manager = \Drupal::entityTypeManager();
  return $entity_type_manager->getStorage('aws_cloud_elastic_ip')
    ->getQuery()
    ->condition('cloud_context', $cloud_context)
    ->notExists('association_id')
    ->execute();
}

Let me know if these fixes should be part of this patch, or another ticket?

@yas As we talked about yesterday, I think the refactoring can happen in another issue ticket. The patch here works as expected and will suffice for the use case we talked about.

@yas, Thank you for the patch. It looks good to me. I do have two comments below. Let me know what you think.

1. +++ b/modules/cloud_service_providers/aws_cloud/aws_cloud.module
   @@ -2187,44 +2188,120 @@ function aws_cloud_form_cloud_config_aws_cloud_add_form_submit(array $form, Form
   +/**
   + * Validate if the credentials has DescribeInstances permission or not.
   + *
   + * @param array $form
   + *   An associative array containing the structure of the form.
   + * @param \Drupal\Core\Form\FormStateInterface $form_state
   + *   The current state of the form.
   + */
   

   I think we should have a bit more documentation regarding why we are doing this validation.

   We talked about this over Slack, and it still took me a few times reading the code to understand why we are doing this.

2. +++ b/modules/cloud_service_providers/aws_cloud/aws_cloud.module
   @@ -2187,44 +2188,120 @@ function aws_cloud_form_cloud_config_aws_cloud_add_form_submit(array $form, Form
   +      'ini_file' => \Drupal::service('file_system')->realpath(aws_cloud_ini_file_path($cloud_context)),
   

   Maybe in another ticket, this is a use case where we should add a way to call the EC2 Service without having the write the ini_file first.

   That way, we don't have to manage writing/deleting the ini_file.

   Perhaps another issue to do that refactoring?

@yas, Thank you for the detailed explanation. This looks good to me.