Add tunnelled operation to Receiver class

[davidjwbbc]

Context

The Transmitter class can take the address of a UDP tunnel endpoint in its constructor, however the Receiver class has no configuration to enable it to receive encapsulated FLUTE multicast packets via a tunnel. This is an imbalance in the implementation.

Requested Feature

The Receiver class should add optional parameters to the constructor to enable tunnelled reception (as was done for the Transmitter class). Alternatively an alternate Receiver constructor method, for tunnelled operation, could be added if it is more efficient.

Further more it would be useful for the Receiver to subscribe to the GTP-U encapsulated multicast stream sent from the MB-UPF to gNodeB's for multicast/broadcast traffic. It would be desirable to be able to indicate to a Receiver that the tunnel listening address is actually an SSM to subscribe to and that the encapsulated packets will contain an extra GTP-U header.

Suggested API

Here are the suggested interface changes to add tunnelled operation to the Receiver class:

class Receiver {
public:
    Receiver( const std::string& iface, const std::string& address,
          short port, uint64_t tsi,
          boost::asio::io_context& io_context,
          const std::optional<boost::asio::ip::endpoint>& tunnel_address = std::nullopt,
          const std::optional<boost::asio::ip::address>& tunnel_source = std::nullopt,
          const std::optional<std::function<size_t(std::vector<uint8_t> &payload)>>& packet_modifier = std::nullopt);
};

[rjb1000]

@davidjwbbc: So this issue is effectively about migrating the tunnel decapsulation code from the "bridge" thread in @dsilhavy's test harness to rt-libflute's Receiver class (with some extra address checking).

[rjb1000]

Stripping the GTP-U header doesn't feels like something that a generic FLUTE library should be asked to do, however.

I wouldn't be in favour of designing it that way. A better design pattern would be for the controlling application to pass in a "helper" function that the library invokes to do application-specific mangling of packets before the generic code in the library starts processing the ALC/LCT payload.

[rjb1000]

In general, however, I am in favour of making the library slightly more flexible in dealing with encapsulated incoming packets.

@jordijoangimenez's MBSTF Client could then take advantage of these features.