feat: implement native Unix Domain Socket support

[Piyush0049]

• Extend listeners config to natively support UDS paths
• Bypass DNS resolution for local socket paths
• Fix ntoa usage across all core modules and plugins to prevent crashes
• Identify UDS as a secure loopback connection to permit guest login
• Add integration tests for connection lifecycles and pub/sub routing

Proposed Changes

This PR introduces native support for Unix Domain Sockets (UDS) across the RabbitMQ core and plugin ecosystem, closing Issue #7311.

As noted by @michaelklishin and @jvary in #7311, the primary roadblock to implementing UDS previously was that various monitoring paths, CLI tools, and plugins implicitly assumed a (hostname, port) pair, causing crashes when they received a {local, Path} tuple.

To resolve this without breaking the ecosystem, this PR systematically audits and hardens those paths:

1. Core Networking: Added {local, _} as a recognized loopback connection in rabbit_net:is_loopback/1, allowing the default guest user to securely authenticate over local sockets.
2. Monitoring & Web Server: Replaced inet_parse:ntoa with the UDS-aware rabbit_misc:ntoa inside rabbit_cowboy_stream_h.erl. This ensures the Management UI and Prometheus endpoints no longer crash Cowboy when access logs are generated for a UDS client.
3. CLI Diagnostics: Rewrote interface formatting in the Elixir CLI codebase (listeners.ex) to gracefully handle non-IP interfaces, preventing rabbitmq-diagnostics listeners and report from crashing.
4. Plugins: Safely bypassed DNS resolution and replaced inet:ntoa assumptions in MQTT, Web STOMP, and HTTP Auth backends.
5. Testing: Added rigorous end-to-end data plane testing (test_uds_publish_consume) in unix_domain_socket_SUITE.erl to guarantee payload integrity over local sockets.

Maintainers: As this touches several core networking and monitoring formatting paths, your review and inputs are heavily appreciated! I'm fully open to iterating on this based on your feedback.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
This is simply a reminder of what we are going to look for before merging your code.

• Mandatory: I (or my employer/client) have have signed the CA (see https://github.com/rabbitmq/cla)
• I have read the CONTRIBUTING.md document
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request