Fix: flow control issues

[pvanderlinden]

This fixes flow control issues during the "Change Grip/Order" in 2 cases:

• the simple fix is during "Change Grip/Order" when the controller is not connected yet: don't send state while we have no player assigned yet
• more generic fix is during "Change Grip/Order" when the controller is already connected and has player assigned (some games do this): lower send buffer to make "push back" to the process before there is a very long wait time before the buffer is cleared out.

Would be good to test this first with multiple switches.

[mart1nro]

Hey, I tested the "don't send state while we have no player assigned yet" fix and it improves pairing a lot, thanks.

I don't understand the fix with lowering the send buffer though. I was under the impression that sock_sendall just sends all data immediately and I don't see any difference if I lower the send buffer size on my side.
Can you give me an example, where this improves the performance and how to measure it?

[pvanderlinden]

I have still one issue (but it might be pre-existing), one in 20-30 connections, the first button you press hangs (it will wait for await controller_state.send() forever). I'm not sure if this existed already, if it comes from the other change I made, or if it comes from the buffer change.

On sock_sendall: it will put it in the send buffer of the socket. Usually the actual send will catch up with it so fast, that you don't really notice this. But in the case of this bluetooth socket and the switch controller dialog: we send more data per second then the reduced data rate during this dialog. The python program wont notice this untill the buffer is full, at which point sock_sendall will wait until it can put data in the buffer again, which is about 4 seconds with the default buffer size. You will see that if you record how long the sock_sendall call takes during the controller dialog. (Also see the "baud rate" note here: https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering