Mode select should download missing relation members on start

[slhh]

Mode select does only check for missing selected elements in the graph, and remove them from the selection.

Instead, iD should download missing elements in mode.enter(), and postpone execution most of its current code to the last callback, if a download was required. I already did this in the (unfortunately unreviewed) PR #3631 to make #3604 useable.

In addition selected elements and also their members shouldn't be unloaded.

We should also consider loading members of selected relations, which would be a benefit for some operations and the member editor, but for performance reasons we should do this asynchronously, or on user request only.

To do it on user request, we can make an explicit download operation available for selection containing at least one relation, which has inclompletely loaded members.

In case we disable some operations due to incompletely loaded data, clicking on the disabled icon could download all required data, and make the operation enabled in this way.

[bhousel]

What's the worst case scenerio?

I'm imagining that a user would click on something and unknowingly kick off a 5 minute download pause.

[slhh]

@bhousel
As regards downloading missing selected elements only, the worst case data amount depends on operations, which add unloaded elements to the selection.
The current operations don't seem to do this, provided that selected elements aren't unloaded. And I think future operations won't massively do so. Downloading a few of such elements, doesn't seem to be an issue.

The worst case scenarios for the two proposed explicit download options would be a real problem. Therefore, the user needs to be able to cancel, maybe by unselecting, or we can add a progress bar with a cancel button.

As regards downloading members automatically, we might restrict this to direct members only. This would already be sufficient for the raw member editior, and to sort routes and multipolygon rings, but not to render multipolygons well.
This seems to restrict the realistic worst case scenario to downloading a few thousand elements, which might be acceptable due to downloading asynchronously.

We might also issue full relation download requests asynchronously, as the worst case would be restricted due to the API limits. Mabe, we can do this for multipolygons only. This would allow to render at least a selected multipolygon correctly, provided that the call did not fail.

[bhousel]

As regards downloading members automatically, we might restrict this to direct members only. This would already be sufficient for the raw member editior, and to sort routes and multipolygon rings, but not to render multipolygons well.
This seems to restrict the realistic worst case scenario to downloading a few thousand elements, which might be acceptable due to downloading asynchronously.

I think I would be ok with storing the adjacent undownloaded way IDs in a special buffer, and scheduling download of those things whenever iD is idle. We can use loadMultiple to chunk the requests into a single API call.

Or maybe use relation/full API call but not for multipolygons or boundaries.

[quincylvania]

I made it so upon selecting a relation, iD will schedule the download of up to 450 members when idle. We can play with this number, but I only saw iD hang a couple seconds at most. If a relation has more than 450 members, then more will download when you select it again. This functionality seems quite useful so far, especially combined with showing features at any zoom level. The next step is #6656.

@slhh Are there other instances where an undownloaded featured can get selected? I can't think of any. I'd like to close this issue since I'm not sure what other work would go into it.

[quincylvania]

Closed this since it seemed all taken care of and changed the name to reflect what I actually did.