Support multiple container ports

[networkprogrammer]

What is the current behavior?
The portMapping list of the task definition only lists 1 port as defined in task_container_port. Since target-group lists container_port, that value should be used to populate portMapping

Terraform fails when trying to map TG container port to a non-existent portMapping

 Error: failed creating ECS service (ecs-fargate-example): InvalidParameterException: The container ecs-fargate-example did not have a container port 5672 defined.
│ 
│   with module.fargate.aws_ecs_service.service,
│   on .terraform/modules/fargate/main.tf line 295, in resource "aws_ecs_service" "service":
│  295: resource "aws_ecs_service" "service" {

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Example code
https://gist.github.com/networkprogrammer/3c64d16d379098260309fea2e8aa7af4

What is the expected behavior?
Ideally, the container port should be picked from the tg's container port. That way AWS does not complain about port mapping not existing

Details
I have an nginx container listening on multiple ports. With task_container_port being used to populate port-mapping, I have to run multiple instances of the same container with task_container_port set to different ports, although they do the same thing.

Software versions?
Terraform v1.1.6
on linux_amd64

• provider registry.terraform.io/hashicorp/aws v4.5.0
• provider registry.terraform.io/hashicorp/random v3.1.1

umotif-public/ecs-fargate/aws: 6.4.2
umotif-public/alb/aws: 2.X

[Ohid25]

Thank you for raising this issue - we've managed to identify the bug in the module that prevents multiple port mappings.

We've added this to our backlog and will work on this when we are able to.

[networkprogrammer]

I created PR #59 for this. Please review and merge as needed

[networkprogrammer]

This issue still exists and should not have been closed. I submitted a PR #59 to help facilitate the functionality that this issue mentions

[Ohid25]

This is now solved as a part of @networkprogrammer's PR in 6.5.0.

Thanks again @networkprogrammer for the contribution!