mssql PMDA: update default driver to 18, add trust_server_certificate option

[natoscott]

ODBC Driver 17 for SQL Server has reached end of support. Driver 18 is the current release but enables TLS encryption by default and rejects self-signed certificates, causing the PMDA to fail at startup with:

SSL Provider: certificate verify failed: self-signed certificate

This is the common case on Linux SQL Server installs which use a self-signed certificate by default.

Changes:

• Update default driver from 17 to 18 in pmdamssql.python and mssql.conf
• Add optional trust_server_certificate key under [connection] in mssql.conf that appends TrustServerCertificate=YES to the ODBC connection string
• Remove stray debug print("trusted?", self.trusted) from startup path

The new option defaults to false so existing deployments with valid CA-signed certificates are unaffected.

Tested on SQL Server 2025 (Linux) with ODBC Driver 18.

[kurik]

@natoscott The patch looks good. However if you do not mind to wait for a few days, I would like to understand what might be consequences for some older platforms like MSSQL running on rhel-8.10 or so. I guess it takes me 2-3 days to prepare the environment and test it.

[natoscott]

@kurik sure thing, no rush.

[kurik]

@natoscott I have tested upgrade scenarios as well as I did some compatibility checks with older MSSQL versions and all seems to work correctly. The only issue is failing test 1337. This test was a bit unstable even with the v17 driver, however with the v18 driver it fails reliably. The error message is:

1337 19s ... - output mismatch (see 1337.out.bad)
8c8
< Check mssql metrics have appeared ... X metrics and Y values
---
> Check mssql metrics have appeared ... 1 metrics and Y values
10,12c10,15
< mssql.general.logins is in range
< mssql.general.logouts is in range
< mssql.latches.latch_waits is in range
---
> mssql.general.logins has value of PMCD
> mssql.general.logins is NOT in range 7.2 .. 8.8
> mssql.general.logouts has value of name
> mssql.general.logouts is NOT in range 7.2 .. 8.8
> mssql.latches.latch_waits has value of name
> mssql.latches.latch_waits is NOT in range 491.4 .. 600.6

With the exception of the failing test, I am OK to merge this PR.

[kurik]

Upon closer inspection of the failing test, the issue is that trust_server_certificate is not set to true in the /etc/pcp/mssql/mssql.conf file. From a PCP testing perspective, I am unsure whether to classify this as a test issue or a system configuration issue.

Fixing this makes the test pass.

Note: I am using MS's official MSSQL containers for the testing: https://mcr.microsoft.com/artifact/mar/mssql/server/tags

[kurik]

One more ( hopefully the last :-) ) comment regarding the test: The test uses sqlcmd command which is part of the mssql-tools. However Microsoft, together with the odbc update, upgraded also the mssql-tools (see i.e. this article). Unfortunately the upgrade of the mssql-tools has changed the path where sqlcmd command is located. For v17 it was /opt/mssql-tools/bin/sqlcmd while for v18 it is /opt/mssql-tools18/bin/sqlcmd. As the path to the sqlcmd is hardcoded in the 1337 test, the test fails (not run) when only the new (v18) version of mssql-tools is installed.