added security levels to CharacteristicConfig with linux implementation

[gkong]

This commit adds a new type - SecurityLevel - and adds instances of it to CharacteristicConfig, for each of: read, write, notify, and indicate.

The default (zero) value is no encryption, so existing user code should be unaffected.

A godoc-visible comment notes that setting a non-default value may result in the peer initiating a pairing operation.

This commit includes a linux implementation which has been tested on Alpine linux. It passes smoketest-linux. If user code specifies a non-default SecurityLevel on any other platform, it will be silently ignored.

Here is a working example CharacteristicConfig which includes a non-default security level:
{
Handle: &rxChx,
UUID: rxUUID,
Flags: bluetooth.CharacteristicWritePermission |
bluetooth.CharacteristicWriteWithoutResponsePermission,
WriteSecurity: bluetooth.SecurityEncryptedAuthenticated,
WriteEvent: func(client bluetooth.Connection, offset int, value []byte) {
fmt.Printf("RX (%d bytes): %s\n", len(value), string(value))
},
}

[gkong]

i forgot to mention - this pull request addresses issue #72 for the linux platform.

[gkong]

Here is some more info about the portability of this proposed change.

The SecurityLevel members added to CharacteristicConfig are intended to map to BLE GATT security properties that exist at the characteristic level across platforms:

• encryption required
• MITM protection (authenticated pairing)

These properties exist in:

• BlueZ (via characteristic flags / permissions)
• CoreBluetooth (via CBAttributePermissions / CBCharacteristicProperties)
• Windows (via GattProtectionLevel)

While this PR only includes an implementation for the Linux/BlueZ backend, the API is not Linux-specific and is designed to map cleanly to other backends when implemented. There are some nuances in how characteristic security properties are implemented in the various platforms, but this API can handle them. For example, CoreBluetooth only exposes a single encryption level, so both of the levels in this PR would map to the single level in a future CoreBluetooth peripheral implementation. This still results in correct behavior, but with reduced granularity on that platform.

This change does not address LE Secure Connections, because LESC is a connection/pairing-level behavior rather than a per-characteristic setting. Support for LESC could be added in the future as an adapter- or connection-level setting, which would be compatible with the API changes in this PR.