Add EATT Support

[zxzxwu]

No description provided.

[zxzxwu]

Using this PR as a discussion thread.

@barbibulle Client-side implementation of EATT is quite easy, while the server side is much more complicated, because Connection argument has been widely passed to attribute value handlers. Changing them to Connection | l2cap.LeCreditBasedChannel will lead to a large amount of type checking errors and indeed they are actually not handling EATT.

Some solutions I come up:

1. Add a new AttributeValueV2 / CharacteristicValueV2 to handle EATT attributes.
2. Reuse AttributeValue and always pass connection to them, and transaction will be rerouted by the server, but this may lead to some issues.

[zxzxwu]

Another problem is that isinstance(bearer, Connection) will lead to circular imports.

A workaround could be to introduce Protocols like

class EnhancedBearer(Protocol):
  connection: Connection

so that isinstance can just check if bearer is enhanced. Still, this may make users hard to cast the actual type.

Or we can still pass actual classes as signatures, and only use protocols to determine types inside Bumble.

[barbibulle]

Maybe a simple option is to continue using Connection as the context for read and write in AttributeValue. That's sometimes useful for a server to know which device is making a request, but we probably don't need to be as granular as individual bearers: there's not much difference between two bearers from the same peer, so I don't see a good use case for a read or write callback needing to know the actual L2CAP channel.
For notifications and indications, the server should be able to keep track of the subscribers for each bearer (instead of for each connection currently). When calling notify_subscriber or indicate_subscriber, all the subscribers on all the bearers for that connection would be notified. The only scenario that wouldn't be supported is to notify only on one bearer but not another on the same connection, but I don't think that's something that really needs to be supported.

[zxzxwu]

Maybe a simple option is to continue using Connection as the context for read and write in AttributeValue. That's sometimes useful for a server to know which device is making a request, but we probably don't need to be as granular as individual bearers: there's not much difference between two bearers from the same peer, so I don't see a good use case for a read or write callback needing to know the actual L2CAP channel. For notifications and indications, the server should be able to keep track of the subscribers for each bearer (instead of for each connection currently). When calling notify_subscriber or indicate_subscriber, all the subscribers on all the bearers for that connection would be notified. The only scenario that wouldn't be supported is to notify only on one bearer but not another on the same connection, but I don't think that's something that really needs to be supported.

Good idea. Let's use this structure first, and if we really need per-channel request we can still add them in the future.

[zxzxwu]

I found that we still need another class - since at least CCCD needs per-bearer control.