Fix: support TLS for HTTP and MQ connections

[odesenfans]

Summary

Fixes security finding M1 from the internal review: the client previously hardcoded plaintext http:// for the aiohttp base URL and used plaintext AMQP for aio_pika.connect_robust(...). When the P2P daemons are not co-located with the client, credentials (including the MQ password) traverse the network in cleartext.

This PR adds opt-in TLS support to make_p2p_service_client so cross-host deployments can encrypt both transports.

New parameters

make_p2p_service_client gains four optional parameters:

• http_use_tls: bool = False - when True, the base URL uses https:// instead of http://.
• http_ssl_context: Optional[ssl.SSLContext] = None - optional custom SSLContext. When http_use_tls=True and this is None, aiohttp's TCPConnector receives ssl=True (default verifying context). When provided, it is passed through verbatim.
• mq_use_tls: bool = False - plumbed to aio_pika.connect_robust(..., ssl=...).
• mq_ssl_options: Optional[Dict[str, Any]] = None - plumbed to aio_pika.connect_robust(..., ssl_options=...). This is aio_pika's native dict-based API; no translation layer is added.

The MQ parameters are also threaded through declare_mq_objects so it remains usable directly.

Behavior change

None for existing callers. With both http_use_tls=False and mq_use_tls=False (the defaults), the factory takes the same code path as before: plaintext http:// base URL and aio_pika.connect_robust called with ssl=False, ssl_options=None. Existing localhost callers are unaffected.

Out of scope

Credential defaults (e.g. removing guest:guest) and HTTP request timeouts are intentionally left for separate PRs.

Test plan

• Existing localhost deployment continues to work with the call site unchanged (defaults preserve plaintext behavior).
• Setting http_use_tls=True against an HTTPS-enabled P2P daemon successfully completes identify().
• Setting mq_use_tls=True (with appropriate mq_ssl_options and an AMQPS-enabled broker) successfully publishes and subscribes.
• Providing a custom http_ssl_context (e.g. with a private CA) is honored by the connector.