Test message check fixes

[pfmoore]

This fixes a number of tests where the only issue is that the new resolver gives a different message than the old resolver. I've taken the view that changing the test to reflect what the new resolver says is acceptable, at least in the short term.

It's very arguable that the correct approach is actually to make the new resolver give the "correct" message, but it's not clear to me that this would be straightforward to do, and as we have a UX project working on the broarder task of improving pip's messages, it seems reasonable to make a tactical fix for now. If nothing else, the test code will pinpoint where and how the messages differ between the two resolvers, and we can use that as a starting point for any further improvements.

It's not obvious to me to what extent the existing messages are based on implementation details of the old resolver (in which case, it's fair game to change them based on implementation details of the new resolver) or on a conscious decision to display a particular message to the user (in which case we probably should make more effort to review if the new message is an acceptable alternative). But my inclination is to address that sort of question in follow-up PRs, once we have the test suite failures dealt with.

Opinions, anyone? @pradyunsg @uranusjr @brainwane @ei8fdb @nlhkabu

[uranusjr]

Same reasoning—if the message is going to change soon anyway, let’s implement the new messaging. The current message is “good enough.” (I for one had never understood or cared about the difference between “up-to-date” and “already satisfied” before working on this project.)

[pradyunsg]

100% on board.

I'm also really curious to know from user testing if folks find the resolver's current output useful, and how we should change it (if at all).

[pfmoore]

OK, I'm going to take that as confirmation this can be merged. We can always revisit these tests later.

[brainwane]

Thanks everyone. Agreed.