At #5868, I
[suggested](https://github.com/python-poetry/poetry/pull/5868#discussion_r931507885)
that some of the caching that was being reworked could be removed
altogether, because cachecontrol was already taking care of it just
fine.

But now I find myself using an Azure artifacts repository, and it is
returning headers that insist that the client does not do any caching:
```
cache-control: no-cache
pragma: no-cache           
x-cache: CONFIG_NOCACHE 
```
(pypi, by contrast, sets max-age to 10 minutes here).

So I was wrong! And now I am seeing a big performance hit in some
projects where the solve involves overrides and backtracking: and
therefore hitting the legacy simple API repeatedly.

However, we don't need all the mechanism of cachy and its like for this,
a well-placed `@lru_cache()` seems more than sufficient.

This makes me wonder whether it wouldn't be better to do similar for
pypi anyway, and rip out cachecontrol altogether. But let's keep it
simple for now: this is an easy fix to a performance regression.

This avoids trashing connections just to immediately re-create them when
`num-worker` > 10. This should provide a pretty solid speedup on beefy
machines.

I'm not attaching any tests because this would be hard to test and if it
doesn't crash with an unknown keyword argument or something it means
it's probably going to be doing what we expect.

updates:
- [github.com/asottile/pyupgrade: v3.1.0 → v3.2.0](https://github.com/asottile/pyupgrade/compare/v3.1.0...v3.2.0)

requests-toolbelt has released 0.10.0 and 0.10.1 recently. These don't
look to make any backwards-incompatible changes (they only add features)
so poetry should be able to work with them fine.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

# Pull Request Check List

Resolves: #6922

- [-] Added **tests** for changed code.
- [-] Updated **documentation** for changed code.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

required for python-poetry/poetry-core#510

Co-authored-by: Randy Döring <30527984+radoering@users.noreply.github.com>

As in title, switching Python 3.11 in CI from beta to full release

recent flake8-type-checking encourages cast() using the name of the
class rather than the actual class, presumably with the aim that you
might find more things you don't need to import at runtime

however here, consistent with other recent MRs, I've taken the view that
it's better to assert that you have the expected type than to trust that
it's so

`__getattr__` can be cute and all, but it's unhelpful for typechecking
(and human code readers): suddenly any attribute on an object might be
valid, and might return any type at all.

mypy and the unit tests agree that no use is made of the `__getattr__`
on `SitePackages` anyway, so removing it is simply making it clear that
there is no magic.

Co-authored-by: Bartosz Sokorski <b.sokorski@gmail.com>

Updated the outdated copyright year to the present. 
So there will not be a need for any further license year updates

Resolves: #6722

When Renovate bot creates an automated pull request to update Poetry, it
can automatically include the link to changelog so it's easier to find
out what changed.

The URL name has to be one of: 'changelog', 'change log', 'changes',
'release notes', 'news', "what's new" (case insensitive)


https://github.com/renovatebot/renovate/blob/c3a87b687ed44a1a100e0e4f91b81e22b7c32482/lib/modules/datasource/pypi/index.ts#L130-L140

Co-authored-by: Bjorn Neergaard <bjorn@neersighted.com>

also fix formatting for some older entries

updates:
- [github.com/asottile/pyupgrade: v2.38.2 → v3.1.0](https://github.com/asottile/pyupgrade/compare/v2.38.2...v3.1.0)
- [github.com/psf/black: 22.8.0 → 22.10.0](https://github.com/psf/black/compare/22.8.0...22.10.0)

After having created a lock file 2.0, running `poetry lock` with poetry
1.2.1 results in the following output:

```
The lock file is not compatible with the current version of Poetry.
Upgrade Poetry to be able to read the lock file or, alternatively, regenerate the lock file with the `poetry lock` command.
```

Ironically, the error message proposes to run `poetry lock` which
results in this error message.

Further, it doesn't make sense that `poetry lock` fails because it
creates a new lock file from scratch (in contrast to `poetry lock
--no-update`).

Running `poetry lock` is now also possible if there is a broken lock file.

Resolves: #1196

Introduces Priority enum to help in bookkeeping of repository types.
Additionally specifies parameter 'repository' to 'repository_name' where
relevant.

this is the first poetry version with plugin support, so plugins 
cannot be compatible with any version before 1.2.