Support UAuthority-only UUri for uStreamer use-case

[PLeVasseur]

The uStreamer needs the ability to open connections between UAuthority-level, so we must follow along with the uProtocol Zenoh spec:

Note that there is a special case. If the UUri only contains UAuthority with empty UEntity and UResource, it’s defined as a special form of Zenoh key upr/[byte hexadecimal of UAuthority]/**. It can listen to all the messages sending to a certain UAuthority.

Therefore registerListener should be updated to support this use case.

An example of how to do this can be found in up-client-zenoh-rust.

Note how the in the Rust implementation when we realize it's a special UAuthority-only UUri there is a special control path to ensure we register for all message types:

if topic.authority.is_some() && topic.entity.is_none() && topic.resource.is_none() {
    // This is special UUri which means we need to register for all of Publish, Notification, Request, and Response
    // RPC response
    self.register_response_listener(&topic, listener.clone());
    // RPC request
    self.register_request_listener(&topic, listener.clone())
        .await?;
    // Publish & Notification
    self.register_publish_notification_listener(&topic, listener.clone())
        .await?;
    Ok(())

When I review the C++ implementation, I don't see the same sort of determination performed.

To me it reads like what would happen in the UAuthority-only UUri case we would be in this case:

if (false == isRPCMethod(uri.resource())) {

    z_owned_closure_sample_t callback = z_closure(SubHandler, OnSubscriberClose, arg);

    auto sub = z_declare_subscriber(z_loan(session_), z_keyexpr(key.c_str()), z_move(callback), nullptr);
    if (!z_check(sub)) {
        spdlog::error("z_declare_subscriber failed");
        status.set_code(UCode::INTERNAL);
        break;
    }
    
    listenerContainer->subVector_.push_back(sub);
    listenerContainer->listenerVector_.push_back(&listener);

In that case, we would be able to receive any type of messages originating from the provided UAuthority.

Issues

Request messages

However, we would not appropriately handle Request messages, as for those we'd need to insert them into the queryMap such that later when we attempt to send a Response message the corresponding Zenoh Query can be located. That's a problem.

Response messages

In addition, it seems like Response may also not be handled correctly? I'll say that in the Rust implementation there's a map kept to be able to refer to later when doing a send() on a Request message to ensure that we have registered a listener for the returned Response message.