Add support for OpenSSL provider URIs

[bdesplanq]

Mosquitto currently does not support OpenSSL 3 provider-based key URIs.
In OpenSSL 3 and later, URIs are used to reference private keys and key stores via the provider and STORE APIs (for example, pkcs11: URIs, but this can be any other URI scheme supported by a given provider). This mechanism replaces the legacy engine-based approach used in earlier OpenSSL versions.
According to the OpenSSL roadmap, engine support is deprecated and scheduled for removal in OpenSSL 4, requiring applications that rely on engines to migrate to provider-based implementations.
This pull request introduces a new keyform option, uri. When keyform is set to uri, Mosquitto uses the OpenSSL STORE API to load private keys via provider URIs, enabling compatibility with OpenSSL 3 providers and future OpenSSL releases.

The change has been validated using either a URI private key reference at client side (e.g. mosquitto_sub) and at broker side.

---

Thank you for contributing your time to the Mosquitto project!

Before you go any further, please note that we cannot accept contributions if
you haven't signed the Eclipse Contributor Agreement.
If you aren't able to do that, or just don't want to, please describe your bug
fix/feature change in an issue. For simple bug fixes it is can be just as easy
for us to be told about the problem and then go fix it directly.

Then please check the following list of things we ask for in your pull request:

• Have you signed the Eclipse Contributor Agreement, using the same email address as you used in your commits?
• Do each of your commits have a "Signed-off-by" line, with the correct email address? Use "git commit -s" to generate this line for you.
• If you are contributing a new feature, is your work based off the develop branch?
• If you are contributing a bugfix, is your work based off the fixes branch?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you successfully run make test with your changes locally?

---

[codecov]

Codecov Report

❌ Patch coverage is 10.81081% with 66 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/net.c	3.03%	32 Missing ⚠️
lib/net_mosq.c	6.45%	29 Missing ⚠️
client/client_shared.c	33.33%	2 Missing ⚠️
src/conf.c	0.00%	2 Missing ⚠️
lib/options.c	50.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
apps/mosquitto_ctrl/options.c	73.28% <100.00%> (ø)
client/pub_client.c	79.53% <100.00%> (-0.58%)	⬇️
client/sub_client.c	76.89% <100.00%> (ø)
lib/options.c	48.39% <50.00%> (-0.15%)	⬇️
client/client_shared.c	78.81% <33.33%> (ø)
src/conf.c	72.37% <0.00%> (-0.08%)	⬇️
lib/net_mosq.c	57.32% <6.45%> (-4.24%)	⬇️
src/net.c	61.12% <3.03%> (-4.19%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bdesplanq]

I noticed a similar PR was just submitted that does the same: #3488 . This illustrates there is a demand for provider support :-)
One difference I see is that I choose to add it with a new keyform value "uri" for backward compatibility and to keep the keyform parameter meaningful.
When keyform is pem, then there will still be an attempt to open the file to test that it exists in options.c
Once engines are fully removed from future OpenSSL versions, then the keyform parameter could disappear and uri can be the implied default...
@ralight If there is still an interest in this PR I can add a few test cases for code coverage. If you prefer to proceed with the more recent PR I can close this one instead...

[amananas]

Ahhh yes, last time I checked your PR was not there yet, I should have checked again.

As you pointed out, I chose to avoid a new key type: store providers creation in openssl aims to remove any key type selection by the application, and only retrieve keys based on the URI or path and available providers, so adding a new type was akin to creating a future needed rework to me (at least that's my understanding, stop me there if I'm wrong). Here I wanted to directly follow openssl way of pulling the keys. It does remove the key existence check though, I'm not sure that's a big issue.

As you said, this could be done in a future version, and I'd gladly probe opinions on this, but I do have applications maintenance in mind: introducing a new 'uri' type will create deployment and maintenance tasks for people using it, and fully removing types later on as well.

[bdesplanq]

@amananas I'd be happy with either approach - quite similar in the end. My main interest is to have the provider store loading and uri support built-in in mosquitto since this is indeed the standard way of working for OpenSSL going forward. Then there is no need anymore to maintain this with patches...

[ralight]

Hi both, just to let you know I'm not ignoring this but am letting the dust settle for a while from the 2.1 release before starting to look at new features for 2.2