Fix multiple build warnings (raises cmake_minimum_required and sets OPENSSL_API_COMPAT)

[carstenandrich]

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?

---

This PR fixes multiple build warnings I stumbled upon integrating libmosquitto into a project of mine.
Changes are split into 4 separate commits that address individual issues, to enable cherry picking:

1. raise cmake_minimum_required(VERSION 3.1) to 3.5 to resolve a deprecation warning with CMake 3.27 and above. CMake 3.5 is from April 2016.
2. fix unused parameter warning in mosquitto_void_option() that only occurs when building without TLS support
3. fix unused variable warning in net__socket_connect_tls() by removing 2 entirely unused variables
4. set OpenSSL API version compatibilty macro OPENSSL_API_COMPAT to OpenSSL 1.1. currently mosquitto uses the ENGINE API, which was deprecated with OpenSSL 3.0, causing deprecation warnings when compiling with GCC: src/net.c:566:9: warning: ‘ENGINE_free’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]

Nr. 4 is related to #2944 and #2779. In the latter it was suggested to define OPENSSL_NO_ENGINE to silence the warning, but for lack of documentation on OPENSSL_NO_ENGINE and its possible side effects, setting OPENSSL_API_COMPAT appears to be the cleaner approach. However, migrating from OpenSSL ENGINE to Providers API is probably the only long-term solution to address the TLS handshake issues in #2779 and possibly #2907.