Working on zephyr multi NUS central issues. Added needed capabilities and found and corrected two fatal defects in conn_ctx.c.

[hkswan]

While working on a new version of multi-nus central to correct for missing features.  This work is derived from the public github repository https://github.com/NordicMatt/multi-NUS. 

Issues:

The major Issues addressed in this are.

• the ability for central to manage up to CONFIG_BT_MAX_CONN NUS peripherals
• the ability for central to properly accept and handle long lines of text data from any NUS peripheral terminated by any of CR, LF, CRLF, LFCR characters. 
• the ability for central to properly recover from any type of NUS peripheral abort, connect and disconnect regardless of the order.
• add the ability for any NUS peripheral to additionally advertise membership in a group using the BT_SCAN_FILTER_TYPE_SHORT_NAME (which allows central ignore NUS peripherals, not in the group.)
• the ability to fully decode the content of both the scan packet and scan response packet.

Resolution:

1. issue 1 is set by the soft devices as a maximum
2. issue 2 required use of the conn_ctx.c for per connection caching AND as the implementation of a per-connection packet data caching in order to reassemble full-text lines. The fatal issue found were two missing k_mutex_unlock(ctx_lib->mutex) invocations in the bt_conn_ctx_get and bt_conn_ctx_get_by_id functions causing deadlock.  
3. issue 3 required sorting out the complex issues relative to connection reference counts so that a disconnecting connection is properly detached along with when to enable and disable scanning.  If reference counts for each connection are not handled correctly central will not be able to reconnect to an NUS peripheral after it disconnects for any reason.
4. issue 4 was required to eliminate interference by nonsystem compliant NUS peripherals. As implemented this version of central multi NUS is configured to auto-connect only  to match on the  BT_SCAN_FILTER_TYPE_UUID = BT_UUID_NUS_SERVICE and BT_SCAN_FILTER_TYPE_SHORT_NAME = <your system short name>
5. issue 5 figuring this out was required to retrieve and decoded all advertised data on a connection by connection basis.

At the moment I have a new multi-NUS central project that successfully supports all of the above.  Implementing this was incredibly time-consuming mostly because of the inadequate and fragmented coding documentation with little contextual information or no code comments which required in-depth figuring out and understanding what worked and what doesn't.

As background, I'm an embedded hardware and software engineer and developer with many many years of experience and expertise.

[ovrebekk]

Hi Kent

Have you created a pull request for the issues you fixed in the Bluetooth libraries? 

Then we can review it internally and make sure it gets updated in the upstream repositories. 

As for the improved example you could always create a PR for that too, in case NordicMatt wants to include your changes. 

Implementing this was incredibly time-consuming mostly because of the inadequate and fragmented coding documentation with little contextual information or no code comments

This is a known issue unfortunately. In the end it comes down to resources, but all feedback is appreciated so we can look into how to improve the documentation in the future. 

Best regards
Torbjørn