[Feature] Remote connection UX

[laurensvalk]

Is your feature request related to a problem? Please describe.
At the moment:

• Pairing with a remote happens on calling Remote()
• We disconnect on program exit.

This isn't very convenient when starting and stopping a script. It sort of works for the LEGO remote as it stays on a couple of seconds but it's easy to miss and this is not true for all devices.

It also leads to issues which look like connectivity issue to a new user. See https://github.com/orgs/pybricks/discussions/1376

Describe the solution you'd like
I'm not actually sure yet, but I'm wondering if the current behavior is the best we can do.

Direction 1
Keep everything as is, but just don't disconnect at the end of the program. The next call to Remote() will just pass (possibly with matching name if given).

Disconnection is achieved by just turning the remote off. We could also implement Remote.close() which has been asked for in the past.

Direction 2
Allow connecting before the program. This is more like "pairing" of two devices that are nearby and pressing a button on both. We could be passive scanning while no program is running.

This could be quite nice as you could have a no-code remote control. But this is probably a bit too confusing as there is very little feedback we can give on hubs with just a light.

---

Direction 1 is probably the easiest, and doesn't change the user experience all that much.

Am I missing any (technical) drawbacks to this approach?

I suppose the remote objects and tasks could be made static to the extent that they are not already so they could persist between program runs.

This may also reduce issues like existing a program in the middle of a remote write, though this may require some adjustments.

[laurensvalk]

Some ideas:

The LEGO remote advertising data includes one bit for the state of the green button. So instead of filtering by name as we allow now, we could connect to remotes whose button is currently pressed. (Even if we don't change the UX, this can be a kwarg to the Remote class so you don't have to deal with renaming.)