XL_ERR_QUEUE_IS_FULL when sending large data (Vector hardware)

### Describe the bug
I am using udsoncan to run some diagnostics, including 'Transfer Data'. As part of this, I send 4kB packets using transfer data of UDS (utilising python-can-isotp via udsoncan).

Randomly I get XL_ERR_QUEUE_IS_FULL whilst python-can is part way through.

What I **believe** is happening is that ```xlCanTransmit()``` is being called before it has finished sending the previous message. I've checked the python CAN isotp code and cannot see anywhere that it might be sending a second call to transmit before the previous one has finished.

Only seems to be a problem on a multi-frame message.

Whilst I was debugging, I put a print message after the ```xlCanTransmit()``` and the problem did not occur. I know that the `print` will cause a delay and, I presume, that delay is enough to stop the issue. In fact, I can even do something similar in the python-can-isotp `send` and it has the same effect - i.e. putting a `print` (delay) anywhere in the send chain seems to be sufficient.

Does ```xlCanTransmit()``` not block until the current frame is transmitted? I presume the same issue could occur if two threads were trying to send on the same connection??

Perhaps I am missing a parameter to set?

```python
# This the setup. Adding in isotp_params doesn't stop the issue.
bus = VectorBus(channel=0, bitrate=500000)
tp_addr = isotp.Address(isotp.AddressingMode.Normal_11bits, txid=0x7B5, rxid=0x7BD)
stack = isotp.CanStack(bus=bus, address=tp_addr)
conn = PythonIsoTpConnection(stack)
client = Client(conn, config=config)
```

### Additional context

OS and version: Windows 10 & 11
Python version: 3.9
python-can version: Tried with 3.4 & latest 4.0rc
python-can interface/s (if applicable): Vector CANcaseXL