[Updater] Ensure we no longer test the legacy code path

[brrygrdn]

Follows on from #7128

Now that all well-formed job definitions are routed to an Operation class, the only jobs that can possibly hit the Updater#legacy_run path are those where the attributes do not match real-world configurations.

This PR makes a change to disable the Updater#legacy_run method in our test suite so any existing or new tests which hit the legacy code line will fail.

Having done this, it then addresses two cohorts of failing tests:

• A set of ignore condition tests which are creating new Version PRs but are using job.dependencies as a convenience in their test setup to avoid having to account for N dependencies
  • This fix for these is to adjust the expectations so they only examine the target dependency without using this hook
• A set of tests which target creating a new PR for a specific dependency that were not security updates
  • For this group the tests were mostly checking the same behaviour for updating as for grouping, so I updated them to be security updates to reflect real world conditions and they continue to pass
  • In one case, testing that a nominated subdependency would still result in an update, I moved this into the "Updating a PR" test as this is the scenario we are most likely to encounter and handle this problem
  • Finally, one test outright checks we can create a fresh PR for a nominated single Dependency, which is behaviour we do not actually use in the real world. I've allowed this to continue passing by enabling the legacy code, but it will be removed when we clean up.

Rationale

The overall goal of the Operation classes is to only have concrete code lines for the job configurations we run in the real world, this ultimately means removing a single capability expressed in our tests at present which is to create a fresh Version Update PR for a set of specific dependencies.

This capability definitely seems like something we might want in future, but in keeping with our intent to make the code paths as explicit as possible I think it makes sense to remove it until we need it rather than leave ambiguity.

As a follow-on from the grouped update introduction and as part of the cleanup from this task the updater_spec should be broken up to more thoroughly test the concrete classes which will make it much easier to bring this back with exhaustive testing rather than having one example in the file currently touch this path.

[jakecoffman]

Seems like a good idea!

[jakecoffman]

The other day I was wondering why we had this exception. Nice use of it!

[jakecoffman]

Make sense!