Refactor after adoption of MDA 0.10

[iay]

Now that the UK federation deployment has both moved to MDA 0.10.0 and removed Xalan from its tooling, three of the four current members of the validator farm are no longer needed.

I don't think we should strip everything down to a single validator at this point, however, as one important future use of the testbed will be to test other such migrations while they are in development.

I therefore propose the following refactoring:

• Entirely remove the two validators that are based on MDA 0.9. These are derived from the ianayoung/md-validator:0.9 container. We're not going to return to those configurations, and I don't want to have to think about MDA 0.9 with any of my hats on. This also means that I can mentally retire the 0.9 branch of the iay/md-validator repository, which hasn't really been kept as well up to date as the main branch, partly because Snyk doesn't know how to monitor branches.
  • Review the existing tests and simplify out anything that was targeted at those validators. For example:

override:
 - endpoint : v09
   skip: true
 - endpoint : [v09x, v010x]
   expected:
   - status: error

The override for the v09 endpoint here can be entirely removed, and the reference to the v09x endpoint can be simplified out.

• Refactor the remaining two validators (v010, v010x) into (spitballing names) prod and next, which at present would both work off copies of the current production branch. One sub-task at this stage would be to again trawl through the existing tests and fix them up: ideally, there should be no current need for any overrides. Note, however, that it's not necessarily trivial: the current production branch is closest to the v010x validator in the current configuration, so in the above example it's the override for v010x that will become the baseline. How much of this rototilling is needed will depend on some non-obvious decisions made in individual tests.

[iay]

@alexstuart , @philsmart : this is something which some time back we decided I should just do and explain to Phil when I was done, given that I expected it to be in a more forward-looking state once it had happened. As I'm speaking to Phil soon anyway, I thought it would be better to write it down in some more detail and get some feedback first.

[alexstuart]

I note that it's good to keep two validators in the testbed so that the mechanism for multiple validators is visible on the main branch.