Solver: shorten the skipping message if needed

[erikd]

Also add a test to prevent this regressing.

Closes: #4251

Please read Github PR Conventions and then fill in one of these two templates.

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[erikd]

A trivial project that depends on aeson but requires a version more recent that the latest, built with existing cabal results in:

Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: solver-fix-0.1.0.0 (user goal)
[__1] next goal: aeson (dependency of solver-fix)
[__1] rejecting: aeson-2.2.3.0 (conflict: solver-fix => aeson>=2.3)
[__1] skipping: aeson; 2.2.2.0, 2.2.1.0, 2.2.0.0, 2.1.2.1, 2.1.2.0, 2.1.1.0, 2.1.0.0, 2.0.3.0, 2.0.2.0, 2.0.1.0,
  2.0.0.0, 1.5.6.0, 1.5.5.1, 1.5.5.0, 1.5.4.1, 1.5.4.0, 1.5.3.0, 1.5.2.0, 1.5.1.0, 1.5.0.0, 1.4.7.1, 1.4.7.0,
 1.4.6.0, 1.4.5.0, 1.4.4.0, 1.4.3.0, 1.4.2.0, 1.4.1.0, 1.4.0.0, 1.3.1.1, 1.3.1.0, 1.3.0.0, 1.2.4.0, 1.2.3.0,
 1.2.2.0, 1.2.1.0, 1.2.0.0, 1.1.2.0, 1.1.1.0, 1.1.0.0, 1.0.2.1, 1.0.2.0, 1.0.1.0, 1.0.0.0, 0.11.3.0, 0.11.2.1,
 0.11.2.0, 0.11.1.4, 0.11.1.3, 0.11.1.2, 0.11.1.1, 0.11.1.0, 0.11.0.0, 0.9.0.1, 0.9.0.0, 0.8.1.1, 0.8.1.0,
 0.8.0.2, 0.7.0.6, 0.7.0.4,  0.6.2.1, 0.6.2.0, 0.6.1.0, 0.6.0.2, 0.6.0.1, 0.6.0.0, 0.5.0.0, 0.4.0.1, 0.4.0.0,
 0.3.2.14, 0.3.2.13, 0.3.2.12, 0.3.2.11, 0.3.2.10, 0.3.2.9, 0.3.2.8, 0.3.2.7, 0.3.2.6, 0.3.2.5, 0.3.2.4,
 0.3.2.3, 0.3.2.2, 0.3.2.1, 0.3.2.0, 0.3.1.1, 0.3.1.0, 0.3.0.0, 0.2.0.0, 0.1.0.0, 0.10.0.0, 0.8.0.1, 0.8.0.0,
 0.7.0.5, 0.7.0.3, 0.7.0.2, 0.7.0.1, 0.7.0.0 (has the same characteristics that caused the previous version
 to fail: excluded by constraint '>=2.3' from 'solver-fix')
[__1] fail (backjumping, conflict set: aeson, solver-fix)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most
 trouble fulfilling: solver-fix, aeson

The version of cabal in this PR produces:

Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: solver-fix-0.1.0.0 (user goal)
[__1] next goal: aeson (dependency of solver-fix)
[__1] rejecting: aeson-2.2.3.0 (conflict: solver-fix => aeson>=2.3)
[__1] skipping: aeson; 2.2.2.0, 2.2.1.0, 2.2.0.0, and earlier versions (has the same characteristics that caused the previous
 version to fail: excluded by constraint '>=2.3' from 'solver-fix')
[__1] fail (backjumping, conflict set: aeson, solver-fix)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble
 fulfilling: solver-fix, aeson

[erikd]

If I use a number less that 3 here, a number of the UnitTest tests (4 to 6 from memory) will fail.

[ulysses4ever]

So, when length of xs is exactly 3, cabal will print the entirety of the list but still says "and earlier versions"?..

3 looks like too many still. I'd suggest print 1 and fix the unit tests.

[sebright]

I have a few comments:

1. I think that -v3 should continue to show all of the versions, for debugging or when users need to see which versions cabal considered or their order. Then -v3 could also be used by any existing unit tests that would be broken by this change.
2. It looks like this change would shorten the skipping/rejecting message even when the solver doesn't reject all of the versions. Is that intentional, or did you mean to implement something more like #10926? Another idea is to shorten the list when the solver rejects/skips all of the remaining versions (from the current version to the least preferred version).
3. It might be better to continue listing any installed or linked versions, no matter where they appear in the list.
4. I agree with @ulysses4ever that only one version should be listed, at least when they are all non-linked source versions.
5. There should also be a test for shortening the "rejecting" message.
6. It would help to have a test where the solver rejects or skips multiple versions for one reason and then rejects another version for another reason. This test case would address (2).