Improvement to debug config UX to download client certificates

[worksofliam]

Changes

I realised today while helping a user out that even after VS Code configures the certificates for both the server and client, it never imports the client certificates automatically from the server.

This change will now not only do that, but also improves the wording so that the server certificates cannot be overridden when they have already been created (as it only needs to happen once for the entire system)

Also, this PR adds a warning when trying to debug securely when connecting to the IBM i with an IP address. A hostname is basically required for secure debugging right now because of the way the certificates are setup. This will hopefully be resolved in a future PR.

Checklist

• have tested my change
• updated relevant documentation
• Remove any/all console.logs I added
• eslint is not complaining
• have added myself to the contributors' list in CONTRIBUTING.md
• for feature PRs: PR only includes one feature enhancement.

[worksofliam]

@codefori/core I wonder if I can get some help with this one. This really affects people who use 'secure mode' for debugging.

• Turn on secure debugging, and use 'generate certificates'
  • If the certs already exist on the server, the client cert will be downloaded (new)
  • If the certs do not exist, they will all be generated and the client cert downloaded

[chrjorgensen]

@worksofliam A quick test showed this: With no certificate files on server, when the debug service is started, the certificate files are generated and downloaded - but the debug service is not started...?

This is a bit confusing, since the service was requested to be started - the certificate generation and download should just be additional steps before starting the service. Agree?

[worksofliam]

@chrjorgensen Yes and no.

The reason we don't do it all in one step automatically is because typically the user would follow each step in the Debug Setup walkthrough. There is a step to configure the certificates and then another step to start/stop the debugger.

The reason it's implemented like this is because I needed the granularity for testing, and then it helps the user understand the flow of the setup through the Walkthrough more.

[chrjorgensen]

@worksofliam I understand what you're saying - but I still find it confusing that when I select to start the debug service, then the outcome is certificates been generated and no mention of the status of the service. Could it send a message that I should select start service again?

I approve but hope you will consider my thoughts...

[worksofliam]

@chrjorgensen To confirm you think that if I generate the certificates, but the server is already running, I should tell the user that they need to restart the debug service? That makes sense and is correct, just want to make sure that makes to you before I add anything else here.

[chrjorgensen]

No, not that... If I start the debug service and certificates need to be generated, then the service should be started after the certificate generation. Currently it only generates the certificates and then stops - which makes me think the service is running, which it isn't...

[worksofliam]

Currently it only generates the certificates and then stops - which makes me think the service is running, which it isn't...

That explains it well. So I will, for now, take your approval. I don't want to hijack this PR to solve two issues, BUT, I do think the entire debug service setup needs a complete overhaul. This PR for the time being solves one issue where the client certificates were not being downloaded at all and always overwriting the server certs.

After this has been merged, I will make an issue to get around to cleaning it up, perhaps for 3.0.0.

Deal?

[chrjorgensen]

Deal...