View-based payload for `udpardRxXxxReceive` methods.

[serges147]

Currently udpard receive methods...

• udpardRxSubscriptionReceive
• udpardRxRPCDispatcherReceive
  accept only UdpardMutablePayload as an actual payload to parsed and later released.

Problem: it's impossible (without extra data copying) to pre-allocate some fixed size buffer (f.e. 2K bytes), read data from a source (f.e. UDP socket by posix recv), and then pass the buffer to udpard with smaller data size (f.e. 35 bytes heartbeat payload) than it was originally allocated. As a result, udpard takes ownership of the buffer, but in the end it will use INCORRECT 35 bytes size during the buffer deallocation.

Solution: these methods should accept not only UdpardMutablePayload (aka "origin") argument but also const UdpardPayload (aka actual data "view" or "span") information. Something like (names/comments TBD):

struct UdpardFrame
{
    /// Contains the actual data to be used by the application.
    /// The memory pointed to by this fragment shall not be freed by the application.
    struct UdpardPayload view;

    /// This entity points to the base buffer that contains this fragment.
    /// The application can use this pointer to free the outer buffer after the payload has been consumed.
    /// In the most simple case this field is identical to the "view" field above, but it is not always the case.
    struct UdpardMutablePayload origin;
};

BTW, such new UdpardFrame struct could be used also at already existing UdpardFragment, like:

struct UdpardFragment
{
    /// Points to the next fragment in the fragmented buffer; NULL if this is the last fragment.
    struct UdpardFragment* next;

    struct UdpardFrame frame;
};

[pavel-kirienko]

Related note: after reading a datagram, the reader should ideally reallocate the buffer memory to reduce waste. We normally allocate ~2 KiB to support jumbo frames, while many frames are much smaller, which causes huge intrinsic fragmentation.