util.prosodyctl.check: turn: Report lack of TURN services as a problem #1749 Rationale: It seems unlikely that someone who has not configured any TURN service runs 'prosodyctl check turn' expecting this to be okay.

net.server_select: Restore dependency on LuaSec to soft for tests server_select is used in e.g. storagemanager tests, and some of the CI runners are lacking LuaSec, which resulted in failures.

net.tls_luasec: Harden dependency on LuaSec We at some point decided that it was okay to have a hard dependency the TLS library. Especially here since this module is meant to contain all LuaSec specifics.

Merge 0.12->trunk

mod_tls: pass target hostname to starttls In case the network backend needs it for outgoing SNI or something.

mod_tls: tell network backend to stop reading while preparing TLS

mod_tls: Do not offer TLS if the connection is considered secure This may be necessary if the session.conn object is not exchanged by the network backend when establishing TLS. In that case, the starttls method will always exist and thus that is not a good indicator for offering TLS. However, the secure bit already tells us that TLS has been established or is not to be established on the connection, so we use that instead.

net: refactor sslconfig to not depend on LuaSec This now requires that the network backend exposes a tls_builder function, which essentially wraps the former util.sslconfig.new() function, passing a factory to create the eventual SSL context. That allows a net.server backend to pick whatever it likes as SSL context factory, as long as it understands the config table passed by the SSL config builder. Heck, a backend could even mock and replace the entire SSL config builder API.

net: isolate LuaSec-specifics For this, various accessor functions are now provided directly on the sockets, which reach down into the LuaSec implementation to obtain the information. While this may seem of little gain at first, it hides the implementation detail of the LuaSec+LuaSocket combination that the actual socket and the TLS layer are separate objects. The net gain here is that an alternative implementation does not have to emulate that specific implementation detail and "only" has to expose LuaSec-compatible data structures on the new functions.

core.moduleapi: Fix 'global' property via :context() - #1748 The 'global' property should reflect whether the module API instance represents the global context or a VirtualHost or Component context. However the module:context() method did not override this, leading the property of the previous module shining trough, leading to bugs in code relying on the 'global' property. See also #1736