Add stickiness support for gateway load balancer target groups

[willoak84]

Is your feature request related to a problem?

The 5-tuple default hash algorithm of the gateway load balancer introduces issues in certaint type of connections, thus making stickiness block needed in the gwlb module definition.

A simple example is an FTP connection in passive mode, that may launch a connection over port 21 and a data connection over a different port. Those two separate session may end up on a different firewall that will use different natgw (assumming centralize inspection), causing the outbound connection to use different public IP.

Generally speaking, the traffic will be allowed but the other endpoint of the connection may drop the traffic depending on their firewall rules. For example if they expect both conenction to be established over the same IP.

Describe the solution you'd like

Gateway load balancer has stickiness option with (link):

1. Source, destination IP (2-tuple).
2. Source, destination IP and transport (3-tuple).
3. Source, destination IP/port and transport (5-tuple).

On aws provider version 3.38 it was introduce "source_ip_dest_ip, source_ip_dest_ip_proto" instead of "source_ip".
The proposed solution suggest to introduce the stickines to allow terraform to change the default behaviour (5-tuple).

The solution is really simple:

1. Add module variable with name "stickiness_target_group" and default value "null".
   variable "stickiness_target_group" {
   description = "See the aws provider [documentation]( description = https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_target_group#stickiness)."
   default = null
   type = string
   }

2. Create dynamic stickiness block under gwlb.tf based on value on "stickiness_target_group" to assign the value to the "type".
   dynamic "stickiness" {
   for_each = var.stickiness_target_group != null ? [1]:[]

   content {
   type = var.stickiness_target_group
   }
   }

Describe alternatives you've considered.

No response

Additional context

This issue affected us on production environment in the specific case of outbound FTP connection with centralize inspection.
The disparate control and data connection took different outbound IPs and target of the connection (behind firewall) dropped the connection because it was not able to match the IPs of control and data to the same connection.

[welcome-to-palo-alto-networks]

🎉 Thanks for opening your first issue here! Welcome to the community!

[sebastianczech]

In PR #317 I prepared solution, but with slightly different approach (details I described in PR).

[sebastianczech]

PR #317 is merged, so I close the issue.