Fixed bug where it's possible for rfcomm tx_credit to go negative resulting in l2cap disconnect from peripheral

[graynode]

While conducting large data transfers over rfcomm I found our device would disconnect after 3-400kb. Looking deeper I found it was possible for the tx credit to go negative which is what was causing the l2cap connection to be disconnected by the other device as this violates the standard.

see attached HCI log
bumble-rfcomm-hci-negative-tx-credit.txt

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[barbibulle]

This fix does indeed prevent tx_credit from going negative (in the case where rx_credits_needed is not 0 but tx_credit is 0), but it goes a bit too far: it prevents sending rx credits in that case, even though it may be desirable to do so.
I think the right fix here is to keep the while condition as it was (i.e "either there's some data that can be sent, or there's a need to send credits), but then in the if rx_credits_needed > 0 case, only include data and set tx_credit_spent if we have tx credits. Something like this maybe:

if rx_credits_needed > 0:
    # Send rx credits
    chunk = bytes([rx_credits_needed])
    self.rx_credits += rx_credits_needed
    if self.tx_buffer and self.tx_credits > 0:
        # Send some data along with the credits
        chunk += self.tx_buffer[: self.mtu - 1]
        self.tx_buffer = self.tx_buffer[len(chunk) - 1 :]
        tx_credits_spent = True
    else:
        tx_credits_spent = False

[graynode]

Good catch. I just tested it locally and it works. I've updated the PR to reflect these changes.