Improvement request: capability disparity of OpenSSL and Mozilla NSS builds: provide same functionality

[jimklimov]

Currently NUT OpenSSL builds allow the NUT upsd data server to certify itself with a PEM certificate+chain+key file, and NUT clients using the libupsclient to initiate STARTTLS and essentially trust anyone. With additional setup in client code (as currently only done in upsmon, see more at issue #3329), the trusted server range can be constrained to a directory with a list of PEM files.

With Mozilla NSS, the server and clients (currently only upsmon again) can use the specified trust database locations, with certificates uploaded there. Clients can present themselves with a certificate, and server can be configured to only talk to clients that present a certificate (any, or those validated by the server database). Clients can also be configured to require that a particular server should respond with a particular certificate subject name.

While the original difference to support the two libraries was largely due to licensing, they now also incur different capabilities and setup for the server and for the (remote) client depending on the build.

This issue is about trying to level the field, and having OpenSSL builds able to do all the same tricks as NSS builds (so the only practical difference is about cert/key setup).

[jimklimov]

After experiments with PR #3330 it generally seems that OpenSSL session init is much more likely to fail, with various problems reported on different platforms. NIT code added by that PR for now will not test the OpenSSL variants in NUT CI runs, but that is of course not tenable long-term (focus of this issue).

A bit more context from @clepple in #246 (comment)