BLE: prefer known recognized services

Yes, yes, we should probably be gathering a list of these.  But this is
a test patch for the Cressi BLE dongle, which has a Nordic UART service
that we should pick.

If we were to have a proper list of known services, we could do that for
the Heinrich Weicamp case above too.  Right now that's another hardcoded
service name.

But let's test this first, and if this works and we end up having a
third case one day, we can make it a real list.

Service number reported by Martin de Weger, and screenshots of his from
the Nordic nRF Connect app show that Nordic calls that service "Nordic
UART service".  Which is a big hint that it is probably - wait for it -
a serial UART service.

Sherlock Holmes has nothing on me.  I can figure out these tough
technical conundrums all day long.

Cc: Martin de Weger <martin@deweger.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

core/btdiscovery.cpp

@@ -82,6 +82,16 @@ static dc_descriptor_t *getDeviceType(QString btName)
 			product = "Genius";
 	}
 
+	if (btName.startsWith("CARTESIO_")) {
+		vendor = "Cressi";
+		product = "Cartesio";
+	}
+
+	if (btName.startsWith("GOA_")) {
+		vendor = "Cressi";
+		product = "Goa";
+	}
+
 	// The Pelagic dive computers (generally branded as Oceanic or Aqualung)
 	// show up with a two-byte model code followed by six bytes of serial
 	// number. The model code matches the hex model (so "FQ" is 0x4651,

core/qt-ble.cpp

@@ -123,6 +123,11 @@ void BLEObject::addService(const QBluetoothUuid &newService)
 		}
 	}
 
+	// Is it a Nordic UART service?
+	// If so, throw out any earlier services, we'll pick this one
+	if (newService == QUuid("{6e400001-b5a3-f393-e0a9-e50e24dcca9e}"))
+		services.clear();
+
 	auto service = controller->createServiceObject(newService, this);
 	qDebug() << " .. created service object" << service;
 	if (service) {

libdivecomputer

@@ -1 +1 @@
-Subproject commit ebbb91142781ce5bcfc055f5b9439835c4c9d947
+Subproject commit 4e809aefd89e67da14d55c8587f1ba001486af2a