feat(installer): Add possibility to provide custom CA bundle certificate

[ppawlowski]

Description

This pull request introduces the --ca-cert flag to the Device Agent Installer that allows to pass the Certificate Authority certificate bundle file to be trusted by the Device Agent.
This change allows to quickly onboard the Remote Instance using the Installer in environments where self-signed certificates have been used to deploy the FlowFuse Platform.

Related Issue(s)

Closes #698

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[allthedoll]

This looks good to merge to me as is. The flag is off by default so ship risk is low, and reusing the stored cert on reinstall is ✨.

I think you should add a smol unit test for InstallCACertificate, though, which can be done in another iteration. Something for the empty/missing/not-a-file cases so a future change can't silently skip the CA.

I have two other points to consider:

• --ca-cert is ignored on --update-agent where it'd be nice to have a doc line or comment
• On Linux/MacOS the file is read into memory and also copied via temp file, so IMHO the os.ReadFile could probably be dropped since the temp file is what gets copied?

This is really nice work though, @ppawlowski and I appreciate the code comments.

[ppawlowski]

--ca-cert is ignored on --update-agent where it'd be nice to have a doc line or comment

Added a comment to readme regarding when the --ca-cert file is used.

On Linux/MacOS the file is read into memory and also copied via temp file, so IMHO the os.ReadFile could probably be dropped since the temp file is what gets copied?

While that's true, I use this approach in a few other places too. The goal is to not pass an operator-provided path straight to cp. The os.ReadFile function handles any filename fine when reading, but the exec.Command("sudo","cp", srcPath, …) passes that path as an argument to cp, and a source path such as -rf or --something-nasty would be parsed by cp as an option rather than a file, plus relative paths depend on the working directory. Reading the file and re-creating it under a predictable temp path/name guarantees the copy step gets a known-safe argument and won't fail on a weird --ca-cert value.
Additionally, for small files like certificates, the extra read/write is irrelevant to performance.