Dealing with Overlapping Slices when calling `MergeStruct`

[wenovus]

@robshakir pointed out that an issue here is in RFC7950, non-config leaf-lists now allow duplicates, making the behaviour more complicated for MergeStruct.

I see 3 possible behaviours for a particular leaf-list node:

Case 1: RFC6020 leaf-list or RFC7950 config leaf-list (duplicates disallowed)

• If leaf-lists are identical, then use the value. This is what we do for other field types: scalar, pointer, binary, or union. Currently we throw an error, which is problematic.
• If leaf-lists are overlapping, then erroring out is correct.

Case 2: RFC7950 non-config leaf-list (duplicates allowed)

Simply concatenate the leaf-lists.

Case 3: RFC7950 non-config leaf-list (duplicates allowed, but not desired by user)

Concatenate and uniquify the merged leaf-list.

---

Since having or not having a path "config/*" within the path tag can be used to determine whether a field is config or state (correct me if I'm wrong), I think each of the three cases can be readily implemented.

The problem is I'm not sure how to actually decide what combinations of these behaviours to offer to the user. It seems a config node can follow either 1 or 2, and non-config nodes can behave according to any of the 3 states, giving 5 unique combinations ((2, 1) is not allowed).

I feel we should just implement one of these, and if users would like other behaviours, they can add them one-by-one under a MergeOpt.

[robshakir]

The config element in the path isn't something that can be relied on -- since the merge needs to be able to deal with non-OpenConfig elements.

I think that you're right that we should implement one of these options as you say -- and then we can figure out what the right approach is in the PR.