Skip service discovery if robust caching is unavailable

For a bonded peer device for which we know robust caching is unavailable, do
not perform service discovery on connection, since we will get a service
changed indication if we need to rediscover.

Thus, our behavior is:
1. If cached DB is empty, do discovery
2. If not bonded, do discovery
3. If we know the peer supports DB hash from a prior discovery, do discovery
4. Else, skip discovery

Then, while doing discovery, skip the DB hash read if it is known to be
unsupported.

Note that on *first* reconnect after bonding, we will do discovery
again. This is because the very first discovery was not cached since it
took place on an unencrypted link. But all subsequent discoveries should
be cached, so reconnections beyond the first should just use the cache.

Test: manual: connect to a bonded phone, verify the db hash is read; connect to
a HID device, verify that discovery is skipped
Bug: 273302622

Change-Id: Ie88185d4f137a85b7db8ab0523d2ce950a4824ae