GitLab

A controller may have more than one instance of state machine to
handle multiple concurrent connections. It's hard to maintain
another state machine in the hci package, and try to keep it
sync'ed with the controller's state.

When a controller accepts a connection, it moves from advertising
state back to idle/ready state. The host has to explicitly enable
it to advertise again.

In the 4.0 spec, where there is only ne connection at a time,
this is plain simple; always re-enable advertising when the
conecction disconnects.

Things get much more complicated when it comes to supporting
multiple connections. First of all, there's no way for the host to
query how many connections the controller support.  What the host
can do is to re-enable the advertising right after it accepts a
connection. However, when the number of connecetions reaches to the
limit of the controller, different controller may have different
implementation/behaviour.

One controller may return "command success" while it doesn't really
re-enable advertising on the spot, but waits until the number of
connections drops. Other controllers may return "command disallowed"
and expect you to retry later, and the host would need to re-eanable
advertising when a connection disconects.

Given that we can't

  * learn how many connections a controller supports,
  * query if the controller is really advertising or not
  * different controllers may have different implementations

the best we can do in the low-level package is probably to make it
transparent to the users, passing errors with more context.

Users should learn the capability of the controller from the vendor,
datasheet, or product description. And figure out which case is the
controller when it reaches to its maximum concurrent connection, and
handle it accordingly - retry at the disconnect event or not.