Bluetooth: Host: Fix GATT Long Read for EATT

[alwa-nordic]

When EATT is established, the value returned from bt_att_get_mtu is not useful to determine the ATT_MTU that applies to an ATT response. This is because bt_att_get_mtu may return the value for a different bearer than the request is serviced on.

A second, related issue is that it's not correct to use the current ATT_MTU of a bearer as the ATT_MTU for a response. That's because it may have changed in-between sending the request and receiving the response. The ATT_MTU applicable for the response is the ATT_MTU of the request (as it was when it was sent).

To fix both of issues, the params struct for the GATT read operation is given a new field that will record the ATT_MTU that applies to this ATT operation. This value is then used to determine if the GATT long read operation is concluded.

The ATT_MTU is recorded from the correct ATT bearer at the moment the ATT request is put on the connection TX queue. Putting the request on the connection TX queue serves to sequence the ATT request TX with any MTU change RSP. This works both for sufficient for UATT, which sends the MTU exchange on the same L2CAP channels, and necessary for EATT, which sends the MTU exchange on the L2CAP control channels.

Fixes: #61741

For reference, Core 5.4 3 F 3.4.2.2 fig 3.1 follows. It illustrates how a bearer's ATT_MTU propagates to requests/responses.

[Thalley]

For additional verification of this, please also add CONFIG_BT_EATT=y to https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bsim/bluetooth/audio/prj.conf

[jori-nordic]

naking on the assert.
edit: else it's fine

[Thalley]

@alwa-nordic What is the reason why you didn't enable EATT in the LE Audio tests? Is it then failing on the write long (since this is only fixing read long)?

[alwa-nordic]

@alwa-nordic What is the reason why you didn't enable EATT in the LE Audio tests? Is it then failing on the write long (since this is only fixing read long)?

I need to get the tests to pass on CI without the LE audio EATT in the first place :). For some reason the test I added in this PR is hanging in CI even though it works perfectly for me locally.

I will try the LE Audio EATT for you after that works. But I don't have any high hopes on this being a silver bullet for whatever EATT problems that affect LE audio. This PR is indeed only affecting the long read API.

Is there maybe a discussion or list of EATT problems that have been observed with LE Audio?

[Thalley]

Is there maybe a discussion or list of EATT problems that have been observed with LE Audio?

No, but I can work towards creating additional issue after this gets merged, to see what might still be missing/causing issues. It's of course also not impossible that the the LE Audio stack needs to do more to properly use EATT

[alwa-nordic]

@Thalley I am aware of your feedback on #61170 that also applies here. Like you suggest, I would like to make a test code lib to remove the duplication. I also think that moment will be a good time to fix all the stylistic issues in the code that goes in that lib. I will create an issue on this.

[Thalley]

Some generic comments, but may not need any change requests

[Thalley]

Didn't finish my review, but will continue tomorrow if this hasn't been merged by then :)

[Thalley]

@alwa-nordic While some of my comments have been related to code formatting, the fact is that the current coding guidelines are not granular enough to provide precise expectations, and none of those formatting comments are blockers for this PR :) So please do not spend too much time on them, and focus on the non-format comments instead

[Thalley]

All blocking comments have been resolved

[Thalley]

Two minor comments, otherwise LGTM