feat: make loading the WebPKI root trust store optional.

[jpace121]

Description

What does this PR do?

Adds a new configuration parameter "use_public_pki" to control whether the root trust store for TLS and QUIC connections will load the default WebPKI root certs or not.

The value defaults to true, maintaining the behavior in main today.

Full disclosure: Gemini 3.8 Flash was used to provide an initial review of this PR.

To verify the configuration is being loaded correctly, I set up a peer config with a TLS endpoint as the only valid endpoint, and the currently valid TLS parameters set up such that TLS works. I then launched a simple publisher process with logging set to trace and looked for the messages that are logged when the webpki root store is loaded and when the user cert is added. I verified the right logs showed up at the right time with the new parameter missing, the new parameter set to true, and the new parameter set to false.

I then redid the test for QUIC.

Why is this change needed?

For my project, I would like to use certificates to identify different participants in the network.

Because I control all of the nodes, I don't need or want a public certificate authority to be used. Digicert's opinion on if something is or is not at some some IP is irrelevant. As set up in main, if I turn on TLS, I wind up having to trust the public PKI system, which is just unnecessary. By setting this new parameter to false, my loaded root cert is the only one that is used, which is what I want.

Not loading the public PKI roots also gives me a sort of lazy method of access control. No one without a cert I sign can get access to my system. As set up in main, I would have to also use the other access control methods like passwords on top of just using certs (not that that is a bad idea.)

Related Issues

Fixes #2764

---

🏷️ Label-Based Checklist

Based on the labels applied to this PR, please complete these additional requirements:

Labels: new feature

🆕 New Feature Requirements

Since this PR adds a new feature:

• Feature scope documented - Clear description of what the feature does and why it's needed
• Minimum necessary code - Implementation is as simple as possible, doesn't overcomplicate the system
• New APIs well-designed - Public APIs are intuitive, consistent with existing APIs
• Comprehensive tests - All functionality is tested (happy path + edge cases + error cases)
• Examples provided - Usage examples in code comments or separate example files
• Documentation added - New docs explaining the feature, its use cases, and API
• Feature flag considered - Can the feature be enabled/disabled for gradual rollout?
• Performance impact assessed - Memory, CPU, storage implications measured
• Integration tested - Feature works with existing features

Consider: Can this feature be split into smaller, incremental PRs?

Instructions:

1. Check off items as you complete them (change - [ ] to - [x])
2. The PR checklist CI will verify these are completed

This checklist updates automatically when labels change, but preserves your checked boxes.

[jpace121]

Looking at the CI:

1. It is looking for one of a list of PR labels, which I'm not sure I can add.
2. It caught that my Eclipse ECA had expired. I've resigned it and relinked my github account. I'm assuming if that job is reran in a little bit after things have a chance to sync, we'll be good.

[jpace121]

I updated the checklist. The only thing I am not sure about checking is "comprehensive testing". I didn't add an unit tests, though there aren't any that I can find for the code around what I added either?

[oteffahi]

Changes look good.

Please add some tests that validate the new config field is taken into consideration. For example:

• A test that expects failure when starting a transport with TLS listener that has no root cert and does not use WebPKI trust store.
• Another test that succeeds in starting a transport with TLS listener with the default config and/or explicit true.

These tests should be added under the zenoh-transport crate.

Additionally, documentation needs to be updated on zenoh.io. Repo for documentation: https://github.com/atolab/zenoh-web