Initial Nimble controller encryption support

[will sanfilippo <wi...@runtime.io>]

Hello:

Initial encryption support has been added to the Nimble controller. By default, encryption is off and is compiled out of the code. To enable encryption, there are two #defines that must be changed in net/nimble/controller/include/controller/ble_ll.h (both must be defined):

#undef  BLE_LL_CFG_FEAT_LE_ENCRYPTION
#undef  BLE_LL_CFG_FEAT_EXT_REJECT_IND

If you enable encryption on the nrf51 you must also change the maximum link layer packet size to 27 bytes (the default is 251). This definition is location in net/nimble/include/nimble/nimble_opt.h (default shown below):

#ifndef NIMBLE_OPT_LL_MAX_PKT_SIZE
#define NIMBLE_OPT_LL_MAX_PKT_SIZE              (251)
#endif

Note that the 27 byte limit for the nrf51 is HW related: the maximum payload that can be encrypted/decrypted is 27 bytes. The chip does support 251 byte frames as long as you dont use the CCM engine. While I suspect we can modify the code such that connections that dont use the CCM engine could use 251 byte frames, the current code forces all connections to use 27 byte payloads if any connection is to be encrypted.

We realize that the current configuration method is a bit clunky (to put it nicely) and we do have plans to change this, but I wanted to commit these encryption changes now in case some folks want to test it.

A final note: there were two Jira tickets added recently (MYNEWT-284 and 285) which discuss current controller issues. One of these is encryption related and affects the nrf52; the other is unrelated to encryption and affects the nrf51. These errors seem to be intermittent enough so they dont affect connections but be warned there are still issues related to enabling encryption (the tickets have more details on the issues).

Thanks,
Will