Refactor flush_tx_queue for VectorBus

[deronek]

In VectorBus class, there's an implementation of flush_tx_buffer relying on xlCanFlushTransmitQueue function of the XL driver. However, this function is a no-op for devices other than XL family, which are discontinued. This means that the library does not support flushing the TX buffer for any Vector devices currently available on the market.
(https://cdn.vector.com/cms/content/products/XL_Driver_Library/Docs/XL_Driver_Library_Manual_EN.pdf)

My implementation of flush_tx_buffer consists of “sending” a dummy message with overrun/highprio flag set. The Vector interface will flush the TX queue after receiving a request to send this message.

Tested on VN5610A, for both FD and non-FD bus. I think it's a good idea to check this on other Vector devices, especially on XL family, to make sure that the implementation works for them all. In our use case, the flush is called after XL_ERR_QUEUE_IS_FULL is raised (e.g. when sending a ton of messages on a dead bus). In previous implementation, any next send request will raise this error if the bus is still dead, because the flush was a no-op. In my implementation, next send requests will not raise an error (until it fills up again).

[zariiii9003]

That's interesting, is that behavior documented somewhere? Or did you talk to Vector support maybe?

[deronek]

That's interesting, is that behavior documented somewhere? Or did you talk to Vector support maybe?

The behavior of xlCanFlushTransmitQueue being a no-op outside XL family is documented in the XL driver library manual linked in the first post.

The behavior of the message flags triggering TX queue flush is documented beside them in the same document.

Regarding the issues, I will fix them today. Unfortunately, I don't think a test for this functionality can be written, since I don't think we can directly access the TX queue to check its content.

[deronek]

Issues with tests and formatting were fixed. I'm open to suggestions on how to test this functionality programmatically.

Additionally, I noticed that my implementation will actually send a message with ID = 0, DLC = 0 and no data. I'm also looking for confirmation whether this will not be an issue in some use cases. I will also add this information to the method documentation.
Below was captured with live CAN bus, VN5610A with receive_own_messages=True.

Timestamp: 1689684485.573268    ID:      000    S Tx                DL:  0                                Channel: 0

[deronek]

Docstring updated. I also added unit tests for this function with the mocked bus, similar to the test that was for the previous implementation.