subclasses of ValueError like UnicodeEncodeError have to be propagated (see #6784)

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

updates:
- [github.com/asottile/pyupgrade: v3.2.0 → v3.2.2](https://github.com/asottile/pyupgrade/compare/v3.2.0...v3.2.2)
- [github.com/hadialqattan/pycln: v2.1.1 → v2.1.2](https://github.com/hadialqattan/pycln/compare/v2.1.1...v2.1.2)

# Pull Request Check List

Resolves: #6928 

<!-- This is just a reminder about the most common mistakes. Please make
sure that you tick all *appropriate* boxes. But please read our
[contribution guide](https://python-poetry.org/docs/contributing/) at
least once, it will save you unnecessary review cycles! -->

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

<!-- If you have *any* questions to *any* of the points above, just
**submit and ask**! This checklist is here to *help* you, not to deter
you from contributing! -->

Bump `xattr` version to `0.10.0`.

This fixes #6891, which is not a problem with the user's environment as
suggested by the maintainer of xattr at xattr/xattr#108, but in fact the
problem of the package which was fixed by xattr/xattr#106.

Looking at the [changes in the version
bump](https://github.com/xattr/xattr/compare/v0.9.9...v0.10.0), there
does not seem to be any significant changes other than shabang
xattr/xattr#106.

Co-authored-by: Moonsik Park <moonsik.park@estsoft.com>
Co-authored-by: Bartosz Sokorski <b.sokorski@gmail.com>

This is an extension of
https://github.com/python-poetry/poetry/pull/6724. I think `pip install`
invoked by poetry should never ask for user input.

Motivation is that it happened to myself and a number of colleagues many
times that poetry got seemingly stuck while it was just waiting for a
user input because of a private pypi repository that needed
authentication.

I hope this is a valuable contribution to a tool I like a lot and would
like to use more and more :)

As written, it seemed to prioritize the older section notation without
clarifying that the older syntax still works but shouldn't be used. This
reorder visually prioritizes the preferred syntax as of 1.2.x while
clearly explaining what the old syntax is during this transition period.

The best next step here would be clearly defining the version in which
dev-dependencies will disappear.

Co-authored-by: Mathieu Kniewallner <mathieu.kniewallner@gmail.com>

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

# Pull Request Check List

Resolves: #issue-number-here

<!-- This is just a reminder about the most common mistakes. Please make
sure that you tick all *appropriate* boxes. But please read our
[contribution guide](https://python-poetry.org/docs/contributing/) at
least once, it will save you unnecessary review cycles! -->

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

<!-- If you have *any* questions to *any* of the points above, just
**submit and ask**! This checklist is here to *help* you, not to deter
you from contributing! -->

Co-authored-by: Mathieu Kniewallner <mathieu.kniewallner@gmail.com>

Found some cases where tests were writing to the Poetry test runtime
environment rather than a mocked local directory. This is an issue,
since it meant that some tests were technically stateful when rerunning
locally.

Added in placeholders for those tests. Tested that this succeeds by
using a build where my Poetry venv was made entirely read-only.

https://github.com/python-poetry/poetry/actions/runs/3371708936 shows
that `set-output` is now deprecated.
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
shows the new way of exporting outputs.

We discovered that in some unknown situations, `distribution.files` can
be `None`, causing the assertion to fail. To handle `distribution.files`
being `None` more gracefully, we treat it as if it were an empty list.

Resolves: #6788 

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.