This checks that the request is valid, replies to the other side in any event (with an accept/reject) and, if accepted, also updates the connection parameters to HCI.

…o copy the data buffer.

The bug that otherwise happens is:
1. HCI.mainLoop gets a byte buffer, reads into it, calls handlePacket
2. handlePacket calls handleL2CAP, which unmarshals into an aclData. This aclData references the original b slice
3. handleL2CAP adds the aclData to a channel
4. handlePacket returns the buffer to the pool
5. Repeat from 1, getting the same buffer _while the aclData referencing it is still in the channel_
Triggering this needs a relatively high data rate, but was possible repeatedly for me with a Polar H10.

…rcap/gatt.

NB: I still intend to drop this fork once I've got everything that I want working and any resulting pull requests to bettercap are merged.

…callee is checking for six bytes, but nobody was checking for 5 bytes :)

…ent sending in l2cap.conn.write to avoid sending unordered segments for the same l2cap channel