elastic-agent should configure the shipper's logging paths

[fearful-symmetry]

CC @cmacknz

Currently, when elastic-agent runs a beat, it passes CLI args that tell the beat where and how to write its logs:

metricbeat -E setup.ilm.enabled=false -E setup.template.enabled=false -E management.enabled=true -E logging.level=debug -E gc_percent=${METRICBEAT_GOGC:100} -E metricbeat.config.modules.enabled=false -E http.enabled=true -E http.host=unix:///tmp/elastic-agent/444d6a84c33a557f7a5afc1148bbb8907101b594aa2a29c4bafe86bd53c2895d.sock -E logging.files.path={...}/data/elastic-agent-8eb334/logs -E logging.files.name=system-metrics-default -E logging.files.keepfiles=7 -E logging.files.permission=0640 -E logging.files.interval=1h -E path.data={...}/data/elastic-agent-8eb334/run/system/metrics-default

However, when elastic-agent starts the shipper, we only get one of args, and its not for logging:

/shipper -E path.data={...}/data/elastic-agent-8eb334/run/shipper-default

This means that the shipper can't write to log files in the same way as the rest of the beats, which makes debugging a tad difficult, as the logs just get dumped to stdout along with elastic-agent's logs.

After some investigation, it appears that this is due to the isSupportedBeatsBinary function in internal/pkg/agent/application/monitoring/v1_monitor.go, which will make sure we only append those args if we have a beat.

So, we should either fix the list of "supported" beats so we get the full logging args, or we need another way of configuring logging settings for the shipper. This is potentially a very easy fix, but it's worth tracking in case we decide the shipper should somehow log differently.

[fearful-symmetry]

Closing, will be dealt with by #221 and #1702