[Bug Fix] Support exporting environment variables with whitespaces

[ManuelPalenzuelaDD]

@### What does this PR do

Previously, when attempting to export environment variables with spaces (e.g. NODE_OPTIONS="-r [...]"), we would get an error message: (e.g. export: not valid in this context: -r). This is because xargs doesn't properly support strings with spaces.

To fix this, we instead advise to export the env variables with a different approach that supports values with spaces.

Possible Drawbacks / Trade-offs

It is a bit more obscure to see what the script is doing.

Describe how to test/QA your changes

Run the script with DD_CIVISIBILITY_INSTRUMENTATION_LANGUAGES=js and see how the NODE_OPTIONS environment variable is now exported correctly (before this change an error was thrown).

[vitor-de-araujo]

@ManuelPalenzuelaDD I would rather make the script print the export statements directly (like, for example, ssh-agent -s does), instead of adding the exports with sed to the script output. The sed does not really ensure we only do exports, because you can still emit multiple commands in a single line separated by ;, you can still emit $(arbitrary_command), etc.

[vitor-de-araujo]

Also, I would quote the output here, like:

Suggested change

	eval $(DD_CIVISIBILITY_INSTRUMENTATION_LANGUAGES=... DD_API_KEY=... ./install_test_visibility.sh | sed 's/^/export /')
	eval "$(DD_CIVISIBILITY_INSTRUMENTATION_LANGUAGES=... DD_API_KEY=... ./install_test_visibility.sh | sed 's/^/export /')"

Otherwise you can still have problems with spaces (multiple spaces will be turned into one, wildcards in the output may be expanded, etc.).

[ManuelPalenzuelaDD]

Yep, I agree. If we do this though we'll need to change the logic of the existing GitHub action to remove the exports from the output (as it pipes them to a file in the format of KEY=VAL). I'll wait to speak to @nikita-tkachenko-datadog about this :)

[nikita-tkachenko-datadog]

Having the script printing export commands and later removing them in the Github action seems like a weird approach to me.
It was not the intention to print something that can be directly evaled, but rather to have something as simple as NAME=VALUE that every user of the script can process easily to fit their needs.

[nikita-tkachenko-datadog]

I am also wary of using eval, even though we verify the integrity of the script with checksum.
Could we use something more restrictive?
For example something along these lines

while IFS='=' read -r name value; do
  if [[ $name =~ ^[A-Za-z_][A-Za-z0-9_]*$ ]]; then
    export "$name=$value"
  fi
done < <(./install_test_visibility.sh)

[ManuelPalenzuelaDD]

@nikita-tkachenko-datadog Yes, I explored doing something like this but decided for the eval approach due to it being more readable for customers (as some may copy paste our instructions from this readme). If we think that the readability problem is a non issue then lets go with this :)

[nikita-tkachenko-datadog]

I don't have a strong opinion wrt eval vs ad-hoc parsing. I am fine with either approach as long as it does not imply adding things to the output to remove them later :)

[ManuelPalenzuelaDD]

👌 Lets go with the more restrictive approach for now as I don't think there are any customers using this script directly. If readability starts being a problem for customers we can evaluate later whether we should change to the alternative eval approach.