feat(relay): allow enabling and disabling of relay HOP advertisement

[dariusc93]

Description

This PR allows the relay to enable and disable its advertisement of the HOP protocol, with the option to automatically determine if the relay should advertise its protocol and function based on its reachability via external addresses (following suite with how libp2p-kad operates)

resolves #4260.

Notes & open questions

1. I do not feel to strongly about using Status. Should we change it to any other name like Mode, etc?
2. Although nothing is mentioned in libp2p spec (besides maintaining the reservation), should we disconnect peers who have an active reservation with the relay when the node is no longer reachable (ie if the node decides to disable advertisement of its protocol, or if there are no external addresses available if its determined automatically) or should we maintain the current reservations until they expire?
3. By default, the status is set to enabled to prevent it from "breaking" relays that do update to a version with this PR merged, but given that the relay need external addresses to operate (the clients with STOP would receive an error if the relay does not have an external address), should have it set to automatic instead, allowing it to be override later on?

Additionally, as a note that this is WIP as this is not tested (yet) and mostly to throw the idea out there based on the issue above (#4260)

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[elenaf9]

Thanks for the PR and sorry for the delay!

Although nothing is mentioned in libp2p spec (besides maintaining the reservation), should we disconnect peers who have an active reservation with the relay when the node is no longer reachable (ie if the node decides to disable advertisement of its protocol, or if there are no external addresses available if its determined automatically) or should we maintain the current reservations until they expire?

I wouldn't disconnect them if there is an active circuit for the peer, because in that case we are already connected to both, dialer and listener.
If not, I am unsure. We currently also don't tell clients if individual external addresses expire, so they might be advertising outdated info anyway. And it might also be that we are just temporarily unreachable in which case we probably don't want to immediately close all active reservations. So I am leaning towards not disconnecting. Or only disconnect if the status was manually set to disable.

[elenaf9]

Few nits, rest LGTM.
Can we have a test for this? 🙏

[elenaf9]

I am sorry for the delay. Some more nits, mostly documentation. Rest LGTM. Thanks @dariusc93!