It will also be much faster to fetch the remote entities in batches
rather than one at a time through LoadEntity.
One bonus/hazard with Multi Fetch GET is that it will get deleted entities
with `visible=false`, rather than returning a HTTP Status Code 410 (Gone).
This will be the only way that we can really do proper undeletion
(Incrementing the current version by 1 is not guaranteed to work. And
if a way is moved, fetching way/full will tell us whether the childnodes
are part of the way, but not necessarily whether they exist or not.)
We must be careful never to merge deleted entities into the real graph.
e.g, a deleted node will not have a 'loc' attribute, so code that assumes
every node must have a `loc` will be broken.
So because deleted entities are very special, the output from `loadMultiple`
should only be used for conflict resolution for now.
* store entity's matched features in a graph transient
* replace fn calls to get commonly used _keys and _hidden arrays
* replace lodash calls with faster for loops (in some places)
* always pass graph/resolver as a param
The main problem with the existing logic was that it
did not update the extents of relations when previously incomplete members were loaded.
It was also overly stateful; the various queues and flags
are no longer required.
Fixes#1928.
Fixes#1540.
When recalculating parent ways/relations during rebase, a
graph should not add modified or deleted entities as parents.
Such entities will already be correctly marked as parents or
not.
Graph had the correct behavior for deleted entities, but not for
modified entities. This had the effect that if you split a way
that was partially off screen, and then panned so that the way was
re-retrieved, Graph#rebase would mistakenly add back the original
way as a parent of all the nodes that were split into the new
section, making them appear as shared.
Fixes#751.
