DeleteVariable should clean up _variableOrderSymbols in neighbor factors

[GearsAD]

No description provided.

[Affie]

I hope I understand _variableOrderSymbols correctly.
From how I see it, it is attached to a factor's definition and should not be modified at all.
How else would you know a factor is orphaned and does not have all the variables associated with it?
Its important in IIF also and used there as:
getVariableOrder(fct::DFGFactor)::Vector{Symbol} = fct._variableOrderSymbols

[dehann]

at least one major use is that factors are order sensitive to the variables being passed in and this is where that info is stored

[Affie]

DeleteVariable should clean up _variableOrderSymbols in neighbor factors

I would say a definite no on this, and close issue?

[Affie]

Sorry didn't mean to close

[dehann]

umm i think it’s a definite yes — perhaps we thinking of different things. if you delete a variable, then it cannot possibly exist in a factor lookup? means the factor is incomplete and should fail if evaluated. default should probably be to also delete factors attached to the deleted variable too, no?

[dehann]

As usual, @Affie convinced me to NOT delete from _variableOrderSymbols, and that the error should be found by checking the current neighbors to a factor.

IF a variable is deleted from DFG object, then default is to delete surrounding factors also. This can be avoided with a keyword argument.

If a factor is not deleted and a new variable is introduced, then a new factor must be created by one of the verbs and replace the current factor which has (by this time) a stale but immutable _variableOrderList.

One reason is that deleting and adding variables will not preserve the all important order. Another reason is that deleting both the edges in the graph and variables from this list undermines the test where one compares the two lists against each other -- currently used for orphan test. Third reason is when using the multhypo interface, then the number of variables is specific to that instance of the factor (as in all cases really) and therefore _variableOrderList must be immutable.

[Affie]

Close in favor of #296