Ensuring we throw an error on bad YAML files

[john-science]

What is the change?

Currently, ARMI will except bad YAML files. That is, if you have the same tag twice, it accepts the second one without warning.

This PR makes such bad inputs hard failures.

Why is the change being made?

Chris opened ticket "4 4 3", where he points out you can have two components with the same name in a Block. Which, in the end, is an invalid YAML file. And we should catch that as a hard error.

Though that ticket was about a very specific problem, this solution handles a much wider range of problems. Like duplicate settings and the like.

Unfortunately, as described below, we can only solve the problem for top-level duplicate keys. Sigh.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify that the new/changed code works.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes (location doc/release/0.X.rst) are up-to-date with any important changes.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[keckler]

Is this PR complete? Looking at it, it is not immediately obvious to me how this fixes #433 . In particular, I don't see how this addresses the blueprints section of our input yaml files.

Maybe I'm missing something here or don't understand, so an example or a test explicitly on the blueprints would be helpful.

[john-science]

Okay, I hate the people that wrote the YAML spec.

I thought the problem was yamlize, then I thought it was ruamel.yaml, but no. Apparently, the official YAML spec defines this as a duplicate key, and thus an error:

blocks:
    # things
blocks:
    # stuff

But if the duplicate keys are NOT at top level, it isn't an error:

blocks:
    fuel:
        duct:
            # things
        duct:
            # stuff

So, now we are in the extremely unenviable position that if we want to catch such things we need to write our own YAML-text-parsing tool to go through and find these not-top-level duplicates.

Because, after extensive testing, ruamel.yaml and pyyaml both silently pass on this and they have no tools to throw errors or even warnings in this case.

NOTE: This PR DOES fix the problem of duplicate keys at the top-level though, so we are still keeping this PR. I have tests to prove this works for top-level keys in the PR now.

[john-science]

I also tried the yamllint library, to find our duplicates. But it follows the YAML spec, so it only sees top-level duplicates as errors.

Sigh.

[john-science]

@keckler This PR still has value, but I have removed the original ticket from it. As I don't think we can close that ticket.

[keckler]

Is there not a more specific exception that we can assert here?