Rejected Node Expansion Create Undo Steps

[everbeek]

When I trigger a large expansion, then cancel it, an entry is made in the undo breadcrumb trail. Might have resulted from changes for #517.

Part of the problem is that the term neighbourhood expansion happens in four steps (grab children, parents, compositions, and mappings). The node cap check this currently checked separately for each of those. This interferes with the desired flow. There is still the problem above in addition to this complication. This second problem can be fixed either by allow the expansion to fill up to the current maximum nodes, or by adding a cap check right at the node expansion menu level. See #523 to fix this.

[everbeek]

Fixed for both single phase and multiple phase expansions (mapping, and term neighbourhood):

http://127.0.0.1:8888/conceptPathToRoot.html?initial_vis=paths_to_root&ontology_acronym=UBERON&full_concept_id=http://purl.obolibrary.org/obo/UBERON_0006590 http://127.0.0.1:8888/?mode=embed&embed_mode=paths_to_root&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F81745001&userapikey=&restURLPrefix=stagedata.bioontology.org

I had to move where the expansion set is registered, which could only be performed by yet another....drum roll please....wrapping callback!

[everbeek]

I might have removed a line of code I needed, because I have a case I thought I dealt with, but it is broken. I need to add the undo registering call for when the node cap check does not make use of a deferred callback. Doing so. Could see in that second URL above, when expanding Anatomical or acquired body structure. It loads first a single child node, then tries to grab a huge chunk of other nodes, and only then uses deferred calls. That single child comes in on its own and does not cause the undo event to be registered.