Add TLS-enabled gRPC system tests

[ryanwixon-emerson]

• This contribution adheres to CONTRIBUTING.md.

• I've updated CHANGELOG.md if applicable.

• I've added tests applicable for this pull request

What does this Pull Request accomplish?

This PR adds a number of smoke tests that leverage ni-tls-config to configure TLS workflows for gRPC tests. The existing tests are unchanged and will all continue to get an unencrypted (no ni-tls-config) run, but a small subset of them will get an additional two:

• One run with a full encrypted server (the soon-to-be default for ni-tls-config users)
• One run with a disabled encryption server (uses ni-tls-config, but disables the option to encrypt)

To implement this, two new fixtures are added to manage configuring ni-tls-config, provisioning certificates if necessary, and launching the server + creating the channel. These fixtures are scoped at the function level (note that this is different than the existing session scoped fixture, which is why that one cannot be simply updated to support both).

Test requirements:

• nitlsconfigtest must be present. This PR adds two wrapper functions to interface with it, and if they can't find it, they'll skip the test.
• The tests must be running in a 64-bit Python process, because the nitlsconfigtest scripts cannot interface with the nitlsconfig CLI if not (as it lives in System32 and can't be reached without a hacky solution).

Why should this Pull Request be merged?

TLS support is being rolled out across our RPC-enabled products, in particular grpc-device, which is actively being used in nidaqmx-python. Using secured mTLS will soon become the default method of communication, so we should test these workflows.

What testing has been done?

I ran the system tests on my own VM and confirmed that the new tests are passing. Using Wireshark, I observed:

• The existing tests continuing to run and communicating over port 31763 with no TLS encryption (not using ni-tls-config at all)
• New tests running and communicating over port 31764; some communication used mTLS encryption, and some used plaintext.
  • This aligns with expectations because port 31764 is used to test both enabled and disabled configurations of ni-tls-config.

[zhindes]

Overall this looks good. Thanks for the support for detecting if this is available and xfailing. CAn you update the contributing.md to include instructions for how to run these TLS flavors? Even if we don't expect public contributors to do it, our internal contributors and DO team will want to validate this stuff each release, too.

[ryanwixon-emerson]

Overall this looks good. Thanks for the support for detecting if this is available and xfailing. CAn you update the contributing.md to include instructions for how to run these TLS flavors? Even if we don't expect public contributors to do it, our internal contributors and DO team will want to validate this stuff each release, too.

I'm happy to update the documentation but I'm a little unsure if contributing.md is the right place for this. Running the TLS tests is automatic and done the same way as it is already described there. The trigger that actually makes them run instead of skipping is an installation of nitlsconfigtest (which is something we do not distribute to customers). I'm thinking adding that in could confuse public contributors into thinking that they are expected to find it somewhere.

On the other hand, I'm not sure where else this could go, and I do agree that it should probably be documented at least for internal contributors to get the TLS tests running locally. I suppose a compromise could be to just document it there and specify that if you don't work at NI you won't have what you need to run these outside of the GitHub CI.

[zhindes]

Overall this looks good. Thanks for the support for detecting if this is available and xfailing. CAn you update the contributing.md to include instructions for how to run these TLS flavors? Even if we don't expect public contributors to do it, our internal contributors and DO team will want to validate this stuff each release, too.

I'm happy to update the documentation but I'm a little unsure if contributing.md is the right place for this. Running the TLS tests is automatic and done the same way as it is already described there. The trigger that actually makes them run instead of skipping is an installation of nitlsconfigtest (which is something we do not distribute to customers). I'm thinking adding that in could confuse public contributors into thinking that they are expected to find it somewhere.

On the other hand, I'm not sure where else this could go, and I do agree that it should probably be documented at least for internal contributors to get the TLS tests running locally. I suppose a compromise could be to just document it there and specify that if you don't work at NI you won't have what you need to run these outside of the GitHub CI.

Yep, I'm fine with it stating that its only available to internal contributors.

[zhindes]

wait for bkeryan to approve as well. you don't need maxx

[bkeryan]

Looks good to me, thanks for contributing!