AWS: Adding variables for external security group ingress cidr_blocks and security_groups

What does this MR do?

This change will allow the customization of both the cidr_blocks and security_groups for the ingress rules associated with the security groups for external access.

• Allows customization to allow the external access to be locked down to a particular CIDR block such as a corporate network (default remains the same with 0.0.0.0/0)
• Allows the SG of an external LB to be configured for ingress access. When using an AWS load balancer, the backend systems should only allow access from the SG associated with the LB

With this change, it allows a user of GET to bring their own LB configuration without relying on GET.

Below is an example of the usage of an ELB with gitlab-rails backend instances being added to the LB:

resource "aws_elb" "gitlab_external" {
  name = "gitlab-external-lb"

  security_groups = [
    aws_security_group.gitlab_external_ssh-lb.id,
    aws_security_group.gitlab_external_http_https-lb.id
  ]

  instances = module.gitlab_ref_arch_aws.gitlab_rails.instance_ids

  // Other attributes ....
}

module "gitlab_ref_arch_aws" {
  // Other attributes ...

  gitlab_external_http_https_ingress_security_groups = [aws_security_group.gitlab_external_http_https-lb.id]
  gitlab_external_http_https_ingress_cidr_blocks     = []
  gitlab_external_ssh_ingress_security_groups        = [aws_security_group.gitlab_external_ssh-lb.id]
  gitlab_external_ssh_ingress_cidr_blocks            = []

Once this has been reviewed and conditionally approved I'll add the appropriate documentation into this MR

Related issues

#151

Author's checklist

When ready for review, the Author applies the workflowready for review label:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: setup a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.