TX message guaranteed delivery

[gregjhogan]

It is easy to overflow the TX buffer when sending a large number of messages rapidly. When sending UDS messages you don't want anything to get silently dropped. This change causes the client to pause (leave NAK active) until there is enough room in the TX buffer to process the next USB data packet. Not sure if this is desirable in all scenarios, or even if this is the right way to handle the situation, but it does seem to work.

[robbederks]

Pretty sure this change also means that we need to add a timeout to the openpilot boardd code to prevent it from freezing if the CAN buffers are not cleared.
Another option would be to have disable this NAK'ing for openpilot and reverting back to the old way of just ignoring overflow after a command?
Any thoughts @pd0wm?

[pd0wm]

For openpilot the most recent messages are more important, so it makes sense to drop older ones if the buffer overflows. I would like the to detect and log when this happens though!

[gregjhogan]

I was thinking we should set the timeout low (instead of 0) in boardd and then skip past messages that time out.

[pd0wm]

If I understand correctly, that will result in the same behavior as we have right now?

[gregjhogan]

very close to the same since the ring buffer is pretty small (once a message is in the buffer it will always get sent); could also add an immediate NAK setting for OP but probably not necessary