Unable to save service discovery during bonding makes it impossible to get data from some bonded devices on reconnect

A BLE peripheral that bonds also assumes that the services and characteristics and descriptors discovered during the bonding connection are saved by the client such that on a reconnect, after encryption, service discovery is unnecessary and the peripheral can notify and/or indicate it's data. There are several health devices that do this.

With the aioble library, one is forced to do service discovery every connection in order to subscribe to notifications/indications. However, service discovery is painfully slow, and long before it is done the health device has already indicated/notified its data and by the time one has subscribed (if the device does not disconnect) the data has already been evented and nothing is received.

How to work around this?

Is this a possible work-a-round?

Edit the code so that the start, end, and value handles are made public instead of private
Save these handles and UUID for each service, characteristic, and descriptor discovered
Recreate the ClientService, ClientCharacteristic, and ClientDescriptor for each of the saved items (of interest)
Change the subscribe method such that it uses the saved ClientDescriptor instead of doing further discovery operations to get the Descriptor.

I do not know if that is possible as the devil is always in the details. But to those who are familiar with the inner workings of aioble, is this something one could do, or is it far more complicated that that?

Start by reading aioble's service discovery and subscription flow, including ClientService, ClientCharacteristic, and ClientDescriptor, to understand how handles and UUIDs are currently managed. Determine whether bonded reconnects can reuse saved attributes and subscribe before discovery; done would mean supported devices can receive notifications or indications without repeating slow discovery.