Add status to BleDisconnectedException

[simonratner]

Summary

The status param of onConnectionStateChange provides useful information even when new state is disconnected, since it holds the reason for disconnection, if supplied by the remote peer.

From Bluetooth Core Specification v5.0, Vol 2, Part E:

7.1.6  Disconnect Command

Command Parameters:

Reason: 
  Size: 1 octet

Value:
  0x05, 0x13-0x15, 0x1A, 0x29, 0x3B

Description:
  Authentication Failure error code (0x05), 
  Other End Terminated Connection error codes (0x13-0x15), 
  Unsupported Remote Feature error code (0x1A), 
  Pairing with Unit Key Not Supported error code (0x29),
  Unacceptable Connection Parameters error code (0x3B).

I believe it is also possible to get status 0x8 (Supervision Timeout), 0x3e (Connection Establish Timeout), and 0x16 (Connection Terminated By Local Host) in a disconnect callback, when it is triggered by the local host stack.

Library version

1.4.0

Preconditions

Connection state change event indicating a disconnect with a non-zero status.
Relevant code is at RxBleGattCallback.java#L76.

Actual result

BleDisconnectedException without a status value.

Expected result

BleDisconnectedException with a status value.

[ThunderThrash]

Sorry for my English...
I would like to know if new BleDisconnectedException can return the status 0x81 (GATT internal error) and 0x85 (GATT error) after closing this issue?

[RobLewis]

Possibly irrelevant comment @ThunderThrash: I'm struggling right now with error 0x81, which is reportedly a "generic Bluetooth error", i.e., seems to have no diagnostic value whatever. Enlightenment appreciated!

[hoanglm4]

I think BleDisconnectedException with a status value is great.

[RobLewis]

Just to achieve a bit of "closure" with my previous comment: the "generic Bluetooth error" 0x81 turned out to be that I was attempting to enable notifications when I should have been using indications (or vice versa, forget which). Wouldn't it be swell if there were explicit causes given like this? Even something like "unsupported operation" would be better than "generic error"!

[dariuszseweryn]

@RobLewis Since 1.4.0 operations that are requested but are not supported by the characteristic properties are logged as a warning. There is also an issue #259 which will be released with #239 - it will cause the above mentioned operation to emit BleIllegalOperationException with a explicit cause.

[RobLewis]

I should have clarified that the above error was in some Android-native (non-RxAndroidBle) code I inherited. Rewriting it now with Rx. What a difference!

[uKL]

@Cierpliwy Looks like this is the one we were talking about. Mentioning just to remember about it.