Revise Target Group naming strategy to avoid conflicts

[erikfuller]

Currently, there are challenges when different clusters within the same account or even VPC which define services with overlapping names and namespaces. For example, these issues

• feature request: be able to customize target group names in k8s #315
• Not able to set env var for target group long name via helm deploy #408

Could be addressed by introducing a more robust naming strategy which takes the potential for overlapping names into account.

Internally, we've been discussing a number of options around target group naming chiefly to avoid conflicting names. Here's the TLDR of where we've landed:

1. TG names will have the form k8s-<namespace>-<name>-<random suffix>, including a random suffix so names cannot conflict
2. There will still be some level of truncation on namespace and name based on TG name max length
3. Disambiguation for TG names will be calculated via tags

Likely tags we will include are

• cluster name
• vpc id
• service namespace
• service name
• parent ref type (either route or service export)
• when parent ref == route, also include
  • route namespace
  • route name

While this approach includes a human-readable name with details of the origin k8s service, the TG name on its own can't be parsed to understand precisely where it came from. However, it does solve the uniqueness issue and has other useful properties, such as being able to reference the same service across multiple routes.

We are also considering patching the annotations on different k8s objects with Lattice resource IDs/ARNs to make it easier to find the matching Lattice resource, though that's probably further out.

[graehren]

Closed with PR #457. Will be available in the next release.