Add new checker ListEquals

[barrettj12]

The current DeepEquals checker is not great at comparing lists and maps, and if they are not equal, DeepEquals generally fails to give a complete and concise description of the difference between them.

This is WIP to add a new checker which compares two lists for equality. In the case they are different, we essentially use a "diff" algorithm to find the difference between them. Thus we can give a much more useful description of the difference between two slices, e.g.

... obtained []int32 = []int32{65, 66, 68, 69, 90, 71, 72, 73, 76, 74, 75}
... expected []int32 = []int32{65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75}
... difference:
    - at index 3: missing element 67
    - at index 6: obtained element 90, expected 70
    - at index 9: unexpected element 76

---

The canonical example of where this could be useful in Juju would be the supported series tests in older versions of Juju, when a new Ubuntu version is released.

Here's the output using gc.DeepEquals (spot the difference):

gc.DeepEquals output

Here's the output using jc.DeepEquals (even worse):

jc.DeepEquals output

And the output from jc.ListEquals:

jc.ListEquals output

[dimaqq]

I wonder if the following format would be more readable, though it probably only works for reasonably short arrays:

... obtained []int32 = []int32{65, 66,     68, 69, 90, 71, 72, 73, 76, 74, 75}
... expected []int32 = []int32{65, 66, 67, 68, 69, 70, 71, 72, 73,     74, 75}
...                                    ^^^         ^^^             ^^^

[barrettj12]

@dimaqq : it's a nice idea. Unfortunately I don't think we have any control over the ... obtained ... expected section, since that is controlled by the go-check package. Nor do I have much interest in spending a whole lot of time getting super fancy with ASCII art and the like :)

[manadart]

We already have the SameContents checker, which is order independent.

[barrettj12]

@manadart thanks, I'm aware of that one, this one is different though because it is order dependent.

[tlm]

Seems like a cool idea. I would just ask that a best effort is made to explain the data structure more and what is going on. With fresh eyes this took me 20 minutes to understand and debug in my head.

[tlm]

It seems far more simpler to just make diffs a []string. We don't use the information in the diff for anything else other then generating the string at printing time. Can we not just calculate it at the time we make the diff and store the result?

At the moment anything that implements the Stringer interface could be a diff also.

[barrettj12]

yeah, you're probably right

[tlm]

I think we can clean up the memory allocations here. My 20 minute grok of this suggest we are blowing i.j.8 bytes for every check we perform when we can get away with (i+j).8 bytes.

[barrettj12]

The full table is needed at the end to "trace backwards" and calculate the entire diff. Yes it's O(n*m) in space and time, the onus is on the user to not use this checker for gigantic arrays.

There might be slight optimisations to be made here but I don't think anything more efficient than O(n*m).