fix issue #363 mismatch xml values while deleting multiple key config

[francoisdeturenne]

The xml produced while deleting a config including a multiple key item may display mismatched values, leading to errors from the targeted netconf device. Sorting the keys in the getSchemaKey method of the sharedEntryAttribute fix this issue.

The xml_test.go file is updated with a test case to describe the issue and test the fix (though the fix is not in xml.go file).

[hansthienpondt]

@steiler @alexandernorth I seem to remember vaguely we had some constraints around sorting? The ordering of keys could be defined by the YANG schema right?

[francoisdeturenne]

@steiler @alexandernorth @hansthienpondt I added a sort in the getSchemaKey method to fix the issue, thinking all the keys should be ordered in all cases. The other possible fix is to sort the keys only after the call of getSchemaKey when needed. Would you rather consider this alternative ?

[alexandernorth]

@steiler @alexandernorth I seem to remember vaguely we had some constraints around sorting? The ordering of keys could be defined by the YANG schema right?

Exactly, we intend to use the order of the keys as defined in the schema as it is not necessarily alphabetical and it affects how the paths are constructed/parsed meaning sorting them would cause other issues.

@steiler @alexandernorth @hansthienpondt I added a sort in the getSchemaKey method to fix the issue, thinking all the keys should be ordered in all cases. The other possible fix is to sort the keys only after the call of getSchemaKey when needed. Would you rather consider this alternative ?

Sorry I have not yet had a chance to analyse the issue fully yet - I will be working on that next and then I can see what caused this behaviour to happen - I hope to have time tomorrow and will assess and report back here

[alexandernorth]

My current theory is that in the XML generation we are sorting the keys when we should not be, causing the values to not match the key in the generated xml - this is what I will investigate first

[alexandernorth]

I will have to continue looking into this next week - appologies for that.
I have been able to reproduce the issue, and am now looking into which part of the logic causes it to happen - it seems like the key values are not the right order in the internal tree's parent path, and as the function adding the keys to the final generated xml assumes the path is in the order specified in the schema, we see this missmatch of key/value pairs in the output.

[alexandernorth]

I have been able to find the source of the issue: In the in-memory tree, the keys are sorted alphabetically, and not by the order defined in the schema. There is code in the function xmlAddKeyElements (pkg/tree/xml.go:270) which assumes that the keys are in schema order, thereby creating this mismatch of key->value pairs.
Based on my quick testing, sorting the schemaKeys slice in the xmlAddKeyElements function would be enough to resolve this bug, however I am not 100% sure about the knock-on effects.
Based on usage of the function, I do not see that this would cause other issues, but I think @steiler would need to confirm this assumption

Sorry for the delay in the response

[francoisdeturenne]

Many thanks for your reviews ! I'll change the fix according to your analyses once @steiler is good with it. No worry about the delay, we can work with my current fix in the meantime.