Validate Python user lockfiles & improve tool lockfile error message

[Eric-Arellano]

Checks that interpreter constraints + requirements of the current run are compatible with the lockfile.

InvalidLockfileError: You are using the lockfile at 3rdparty/python/lockfiles/user_reqs.txt to install the resolve python-default (from [python].resolves). However, it is not compatible with the current targets:

• The targets use requirements that are not in the lockfile: ['flake8-plugin==2.3']
  This most often happens when adding a new requirement to your project, or bumping requirement versions. You can fix this by regenerating the lockfile with generate-lockfiles.

• The targets use interpreter constraints (CPython==3.9.*) that are not compatible with those used to generate the lockfile (CPython<3.10,>=3.7). You can fix this by either adjusting your targets to use different interpreter constraints (https://www.pantsbuild.org/v2.10/docs/python-interpreter-compatibility) or by generating the lockfile with different interpreter constraints by setting the option [python].resolves_to_interpreter_constraints, then running generate-lockfiles.

To regenerate your lockfile, run ./pants generate-lockfiles --resolve=python-default.

This also improves the error message for tool lockfiles to say how the resolves diverge:

• You have set different requirements than those used to generate the lockfile. You can fix this by updating [black].version and/or [black].extra_requirements, or by using a new custom lockfile.
  In the input requirements, but not in the lockfile: ['typing-extensions>=3.50.0.0; python_version < "3.10"']
  In the lockfile, but not in the input requirements: ['typing-extensions>=3.10.0.0; python_version < "3.10"']

[Eric-Arellano]

Each commit is distinct, but this is probably easiest enough to review in a single pass.

Thanks @chrisjrn for laying the foundation for this!

[Eric-Arellano]

Question, do we want to list what the relevant input targets were? I know how to implement it, only a question if we want it. I figure more diagnostics are better?

[stuhood]

It would be good for docstring or field naming to clarify that both addresses and requirements are subsets (afaict) of the entire resolve, only used for staleness checks.

My first read of this (without thinking too much about the review title) was that we were passing in all of the requirements that made up of the resolve (which felt upside down, and I was about to comment to that effect).

[Eric-Arellano]

Agreed the names in general are confusing. I think Lockfile(req_strings=) is also confusing. I'm going to punt on this for a holistic rename: #14388

It's a little tricky that interpreter constraints do change how the _RepositoryPex is used, and addresses is used to determine those.

[stuhood]

Question, do we want to list what the relevant input targets were? I know how to implement it, only a question if we want it. I figure more diagnostics are better?

I don't think that that's necessary. The next step after detecting a stale lockfile (I think?) will almost always be regenerating the lockfile, rather than editing a target.