Allow multiple parallel HOGP connections

[benedekkupper]

This is the PR achieving multiple parallel HOGP connections. To allow for this, a new concept is introduced, the hid::session. This object has the lifetime of an HID connection, in the case of USB as long as the device is configured, in the case of BLE from the point where a HOGP attribute is accessed until disconnection. In the case of BLE, each bt_conn needs its own hid::session, and this is the part that's not implemented yet, because I don't know the full context. @kareltucek I ask you to go over this and implement the new TODOs in the changes, and all the adaptations for the new connection switching logic.

I have only done a quick smoke test on this first branch version with UHK60, UHK80 is guaranteed not to work without further changes.

Closes #1549

[kareltucek]

Sorry for the wait!

I have filled in the session handling.

My quick smoke test says:

• usb:
  • uhk -> host works
  • host -> uhk does not - can't connect Agent, not receiving caps lock
• ble:
  • on first connection, the hid session start is called, but sending reports results in -104
  • on a disconnect, the stop callback isn't called

Claude thinks this about it:

1. hid/transport.hpp transport::start attaches tp_ only after the session is constructed, so the sessions' constructor receive_report() calls no-op out (tp_ null) and USB OUTPUT/FEATURE reports (LEDs, Agent) are never delivered.

2. bluetooth/hid_over_gatt.cpp service::make_session never sets conn_session.conn = conn, so get_session/get_session_conn/disconnected never match a connection — breaking report sends (-104) and session teardown.

[benedekkupper]

These two points have been addressed in the last commit, thanks for the detailed analysis! What's still strange, even from simply booting up with USB connection, on each report send the right side prints "Can't send report - selected connection is not ready!" even if the report is still sent over USB. I don't know if this needs to be fixed here, or it's already addressed in your branch.

[kareltucek]

That means that Connections_SetStateAsync(connId, ConnectionState_Ready) is not called. I will look into it.

in your branch

Which branch exactly do you mean?

My aim is to get a working PoC on this branch and just then start tying all the branches into one.

[kareltucek]

Everything seems fine now 😊. Thanks!

One thing that caught my attention - a previously paired connection didn't take - it connected, security got raised, but the ble_app never fired. I had to unpair and re-pair. I assume something in the gatt registration changed and android went after its remembered identifiers, so it is probably nothing.

Will start consolidating open branches and give it a more thorough test then.