Zuul can operate with a broken configuration (ie, a config which
references objects which do not exist). To avoid leaving misleading
error messages on proposed config changes, we suppress reports of
errors which did not originate in the same repo-branch of the change.
However, this means that a change which removes a job defined in one
repo which is still used in another repo will not report an error
(because the usage of the job is in a repo other than the one to which
the change is being proposed).
To correct this, we attempt to uniquely identify errors which are
already present in the layout (whether that layout is one generated for
a parent change, or the actual running layout), and avoid reporting
those errors to the user. In other words, we attempt only to report
new errors generated by the proposed layout.
This isn't perfect, as it relies on a bevy of heuristics to make
a unique key for each error, but that should generally work for this
purpose. However, as a special case, we also do still report any errors
for the current project (as in that case, we're very likely to end up
with duplicate keys as someone attempts to correct an existing error).
This adds a new test for the desired behavior.
This also removes the length restriction on the number of errors we
store, as we need to keep all of them in order to be able to compare
their keys. However, we still only report one error to the user,
and we limit the number of errors that we log.
The LoadingErrors class is slightly more formally structured now to
enable more explicit arguments.
Change-Id: I885a2d3ab6d60402425b879e639c1e597717622a
050c640b0b