Lack of VECTOR_RPT_STATUS_BROADCAST_COMPLETE handling for NULL_ENDPOINT devices (but probably applies to all devices

[peternewman]

Describe the bug
I don't get an RPT Status response from the broker when I send a broadcast or vendorcast message to the NULL_ENDPOINT.

I note your RPT Status docs at https://etclabs.github.io/RDMnetDocs/0.3.0/handling_rdm_commands.html don't seem to mention this case either.

To Reproduce

1. Run up the example broker
2. Run up the rdmnet_device_example
3. Send a broadcast or vendorcast message to the NULL_ENDPOINT of multiple devices
4. Note that there is no RPT Status message received with a vector of VECTOR_RPT_STATUS_BROADCAST_COMPLETE.

Expected behavior
From the standard, 7.4.7.1 Scope Broadcast certainly allows the message I'm sending.
7.5.3 says "The Broadcast Complete message is sent by a Device or Broker once it has finished transmission of an RDM Command PDU or RPT PDU that is addressed to a broadcast UID."
7.5.3.7 says "A Broadcast Complete message informs a Controller that an RDM Command PDU was successfully sent to at least one Device. Since broadcast messages are inherently unreliable, this does not indicate that all Devices received the broadcast message."

9.2.7 is probably the most explicit on this point "In the case of a broadcast message, the Broker shall then send to the originating Controller a Broadcast Complete RPT Status PDU. If the enclosed RDM Command message is also a broadcast message (though this time for RDM Responders), the Broker should expect to receive Broadcast Complete messages from the Devices that were targeted by the broadcast. These messages should not be forwarded to the originating Controller."

I saw you've got the code to discard the device messages, it just looks like the broker is missing its code to send the controller a status message. From my reading of 9.2.7 that's actually regardless of the endpoint it was targeted at, i.e. it should respond with a status message in all cases once it managed to pass the message onto devices.

Additional context
I'm using the example broker and responder apps. Logging as follows:
2024-03-30 22:01:44.000Z [DBUG] RDMnet Broker: Broadcasting RPT message from Controller 7a70:9d00000a to all Devices from manufacturer e574

Likewise if I do a broadcast:
2024-03-30 22:04:02.000Z [DBUG] RDMnet Broker: Broadcasting RPT message from Controller 7a70:9d00000a to all Devices

Wireshark of the vendorcast packet:

RDMnet
    Packet Identifier: ASC-E1.17
    Data length: 88
    PDU: Root RPT, Src: ce61a768-eade-4739-af5c-841bf7a1477d
        Flags: 0xf0
        Length: 88
        Protocol ID: RDM Packet Transport Protocol (5)
        CID: ce61a768-eade-4739-af5c-841bf7a1477d
        PDU: Request
            Flags: 0xf0
            Length: 65
            RPT Vector: Request (1)
            Source UID: 7a 70 9d 00 00 0a
            Source Endpoint ID: 0
            Destination UID: ff fd e5 74 ff ff
            Destination Endpoint ID: 0
            Sequence Number: 0
            Reserved: 0
            PDU: RDM Command
                Flags: 0xf0
                Length: 37
                RPT Request Vector: RDM Command (1)
                PDU: RDM Start Code
                    Flags: 0xf0
                    Length: 30
                    RDM Command: RDM Start Code (204)
                    Remote Device Management, Dst UID: e574:ffffffff, Src UID: 7a70:9d00000a
                        Sub-start code: 0x01
                        Message length: 25
                        Destination UID: e574ffffffff
                        Source UID: 7a709d00000a
                        Transaction number: 5
                        Port ID: 1
                        Message count: 0
                        Sub-device: 0
                        Message Data Block
                            Command class: Set Command (0x30)
                            Parameter ID: Identify Device (0x1000)
                            Parameter data length: 1
                            Parameter data
                                Identify Device: 0x00
                        Checksum: 0x0813 [correct]
                        [Checksum Status: Good]

[ChristianReese]

@peternewman - Thank you for reporting this bug - I've filed a ticket for it.