Discovery Client: do not fall back to FQDN as service name

[mcous]

overview

An MDNS advertisement from a robot has (among other things) the following properties:

• A Fully Qualified Domain Name (e.g. robot-name._http._tcp.local
• Service types (e.g. { name: 'http', protocol: 'tcp' })

The discovery client pretty strictly tries to create a regex to strip the trailing service type / domain name information off the FQDN to end up with a shortname in the app. If the short name extraction fails, the Discovery Client will fall back to using the FQDN as the "name" of the service.

This regex is too strict and fails in various edge cases (not all of which are known, due to lack of debugging information in available logs), causing "phantom" duplicate robots to appear in the app with the FQDN of a known robot.

current behavior

Short name extraction from FQDN can fail, causing fallback to FQDN

steps to reproduce

Unknown, but happens often enough to be noticeable by end users

acceptance criteria / implementation details

In fixing this bug, we should have two goals:

• Make shortname extraction more lenient and therefor more reslient to failure
  • For example, rather than relying on the service advertisement to know we need to remove a trailing _http._tcp, we can just hardcode that into the extractor because we're only every querying for HTTP services
• Increase logging of service advertisements to better diagnose these sorts of issues in the future
  • See Discovery Client: Separate health response data and status in state #5981 for a discussion of switching DC state management to Redux and opportunities for better logs that come with it

[mcous]

Closed by #6154 , will make it to the app in a future wire-up PR