Escape labels on Node Join scripts

[marcoandredinis]

Fixes: https://github.com/gravitational/teleport-private/issues/1883

changelog: Escape user provided labels when creating the shell script that enrolls servers, applications and databases into Teleport.

Enrolling new servers using the UI (Enroll new resource button), generates a script that installs teleport into the machine and enrolls it into teleport.
We now support adding labels to this script, so that when the teleport service presents itself to the cluster, it will advertise those labels.

However, those labels were added into the script without escaping their values.

This PR changes 3 places where user input data was being used:

• when installing the node, it runs teleport node configure --labels <labels>
• when installing as a Application Service, it would put the labels in the teleport.yaml file
• when installing as a Database Service, it would put the labels as resource label matchers in the teleport.yaml file

The source of the first two installation modes (node and app service), labels are sourced from Token.Spec.SuggestedLabels.
For the Database Service installation mode, labels are sourced from Token.Spec.SuggestedAgentMatcherLabels.

For the node, the labels are now escaped before being added into the teleport node configure --labels command.

For the Application and Database installation modes, we keep using the same method we were using but now prevent any escape from the expected flow by creating a new HEREDOC using a quoted starting identifier ("EOF"), which prevents any interpolation of the HEREDOC contents.

---

I think we should be more strict about the labels we accept in the first place, but I'll not add those checks here to keep the PR as specific as possible.

Example A
When the teleport node configure --labels x=y is called, teleport will validate the labels using client.ParseLabelSpec which might return invalid even tho the labels were set as SuggestedLabels.

Example B
Even if the teleport.yaml was generated using teleport node configure --labels x=y it might be the case that the label is invalid.
There's a validation using types.IsValidLabelKey, which is different from the above.

[kimlisa]

what about the EOF heredocs?

[marcoandredinis]

what about the EOF heredocs?

Thank you!