Extension-manager: bridge extensions to the local network by default

[ES-Alexander]

Current behaviour

In a similar vein to #1640, it would be nice if each extension was automatically set up with a network bridge to the local network of the host computer.

With a default approach we could avoid extensions needing to define it manually, and the confusion that may come from doing that.

Expected or desired behaviour

Inject an ExtraHosts binding (e.g. blueos.internal:host-gateway) into the Docker permissions for any extension that doesn't already have ExtraHosts defined. This allows extension code to be obvious when it is connecting to the internal BlueOS network.

---

Considered alternative host addresses include:

1. host.docker.internal
   • This is our currently documented recommendation, and is used in some of our existing extensions
   • It's likely the easiest to find external documentation for this, but also isn't very intuitive for people who aren't already familiar with Docker, which may be many of our potential Extension developers
     • We care more about helping people to learn and use our system than teaching them Docker standards and common practices
2. blueos.local
   • This allows the same code to be run in and outside an extension, which is a nice convenience feature
   • It may run into access conflicts if the developer includes an mDNS receiver in their extension
   • It may cause confusion for developers who are used to using/testing on systems with a custom mDNS address configured (since this address is unrelated to the external address/domain that BlueOS is accessed from)
3. blueos
   • This is nice and clean, but may not seem as much like a URL, which could be confusing

Prerequisites

• I have checked to make sure that a similar request has not already been filed or fixed.

[rotu]

I agree there should be official guidance here. But I think these two suggest different things:

• host.docker.internal means "Docker hosting the service". I expect this even in non-BlueOS environments.
• blueos means "I should expect the BlueOS core services here". In particular, if you have a container running alongside blueos-core, I'd expect this to refer to the peer container. This also has the drawback that it is not googlable.
• blueos.local means "I should connect to whatever is advertising itself as blueos on mdns". I think it's wrong to use this.

I recommend making the host reachable at blueos.internal. I recommend not using blueos because this is not very googlable.

I also think it's a good idea to expose services as subdomains of blueos.internal so e.g. an extension could connect to ws://mavlink2rest.blueos.internal instead of the more opaque ws://blueos.internal:6040.