RFC: Bluetooth: Require the use of `struct bt_l2cap_chan` for all EATT-related operations

[carlescufi]

The goal of this proposal is to give the application full control over traffic and operations on multiple dynamic L2CAP channels that are acting as ATT bearers (i.e. connecting to the 0x0027 SPSM). This requires the use of struct bt_l2cap_chan as an identifier on all of these operations and callbacks/app notifications (i.e. both ways).

• The proposal would be to reuse the bt_l2cap_ecred_* existing APIs for all EATT-related channel operations (creation, reconfiguration and destruction).
• For incoming EATT channels, we would have an EATT server in the stack that would notify the application. Question about the allocation of incoming channels?
• We need to enhance our GATT APIs so that the corresponding struct bt_l2cap_chan is a parameter or part of the callback.
• Deprecate the bt_eatt_* APIs.

Additionally, consider restructuring the different L2CAP channel structure so that it reflects the spec and the nature of L2CAP, and not necessarily BR/EDR and LE. For example, consider having an struct l2cap_fixed_chan and struct l2cap_dyn_chan.

[carlescufi]

https://gist.github.com/carlescufi/11e5a429a705864e42f247d585a14c4b

[Thalley]

One thing not discussed here is that the ATT implementation has a synchronous callback structure, meaning that any request will send a response before handling the next request.

One of the purposes of EATT was to support multiple requests simultaneously, which we won't be able to do with the current callback-based implementation. To properly support EATT we need multiple threads (one for each bearer) or a asynchronous approach to sending responses.

[jori-nordic]

I would obviously vote for an async approach, with the application allocating the working memory, and any other resources for the req/rsp.

[Thalley]

I would obviously vote for an async approach, with the application allocating the working memory, and any other resources for the req/rsp.

Yes please :)