Fix inconsistent handling of constraints comments with backtracking resolver

[mkniewallner]

Resolves #1712.

Investigating the root cause of the issue led to what could be a faulty condition in the backtracking resolver.

self.existing_constraints will always be empty when a generated .txt file doesn't exist yet, but will contain all the generated file dependencies when it does exist, so the condition that is removed by this PR will always evaluate to False for all dependencies in this case.
Consequently, this condition in the writer will also evaluate to False, preventing the retrieval of the constraints annotations when an already existing .txt file is updated.

There may be a specific reason this condition is here, but since the information only seems relevant for annotating the dependencies, it doesn't seem to me that it is relevant.

The PR also adds a specific test that ensures that running pip-compile twice (once with a non-existing .txt file, and once when it already exists) provides the same output for both resolvers. Without the change in the PR, the test fails for the backtracking resolver, but passes for the legacy one.

Contributor checklist

• Provided the tests for the changes.
• Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

• Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[atugushev]

Awesome! Thanks for the fix. Honestly, I don't remember the intention of ireq_key not in self.existing_constraints condition. However, I'm glad the fix works for legacy and backtracking resolvers which is a good signal.

Minor comment below.

[atugushev]

Neat!

[mkniewallner]

Not sure why the CI is failing, but it doesn't seem to be related to this PR, as the same error appears on other workflows (https://github.com/jazzband/pip-tools/actions/runs/3382935861/jobs/5618360528#step:10:257).

[atugushev]

Not sure why the CI is failing, but it doesn't seem to be related to this PR, as the same error appears on other workflows (https://github.com/jazzband/pip-tools/actions/runs/3382935861/jobs/5618360528#step:10:257).

Yeah, that's unrelated to the PR. I'm gonna merge this anyway.