This commit updates some outdated syntax with the modern alternatives.
The changes were applied automatically using pyupgrade (v2.0.1) with the
following command:

```
pyupgrade --py3-plus **/*.py
```

These updates are purely syntactical and there should be no change in
functionality.

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

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

As discussed in #259, the `limit` parameter - to the low-level
`listing.List` and its subclasses, and to various higher-level
functions which ultimately return `List` or `GeneratorList`
instances - is confusing and misleading.

It is passed through to the API calls, and effectively specifies
how many items a single API call will return. But because our
`List` yields a single item at a time and will keep doing API
calls until the API says there's no more data, it does not limit
how many items our `List` will yield, nor specify its chunk size.
It seems natural to expect that `List(limit=10)` or
`page.revisions(limit=10)` will give you a generator that yields
only 10 items, or yields 10 items at a time, but it does not; it
gives you a generator which queries the API in chunks of 10 items
at a time, but will yield every item the API gives it, one by one.

This is probably not ever how we really intended mwclient to work
(there's an old `# NOTE: Fix limit` comment which implies as much)
but it has worked this way for 16 years, so we should probably
not change it just in case someone really has a need to specify
the API chunk size for some reason, or some code somehow happens
to implicitly rely on it behaving the way it does.

So, this keeps the behaviour of the `limit` param wherever it
exists, but triggers a deprecation warning. Everything that had
a `limit` param now also has an `api_chunk_size` param that does
the same thing, but is more explicitly named and does not trigger
a deprecation warning. And everything that had a `limit` param
now also has a `max_items` param that does what it sounds like,
and what people are more likely to want - sets an absolute limit
on the number of items the generator will yield.

For efficiency, if `max_items` is set, neither `limit` nor
`api_chunk_size` is set, and `max_items` is below
`site.api_limit`, we set the API chunk size to `max_items` so
we only retrieve as many items as we actually need.

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

writeapi is being removed

Bug: T294397

Raises an error when ignore=False and the MediaWiki response contains
the `upload.warnings.exists` key. Previously, this warning was logged,
but the call to `Site.upload` succeeded. This could be easily missed by
users, especially when they haven't configured the log level.

As discussed in #197, this renames the `reqs` argument to `Site`
to `connection_options`. The old name still works but triggers a
DeprecationWarning. If you specify both we raise ValueError.

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

Bumps [sigstore/gh-action-sigstore-python](https://github.com/sigstore/gh-action-sigstore-python) from 2.1.1 to 3.0.0.
- [Release notes](https://github.com/sigstore/gh-action-sigstore-python/releases)
- [Changelog](https://github.com/sigstore/gh-action-sigstore-python/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sigstore/gh-action-sigstore-python/compare/v2.1.1...v3.0.0

)

---
updated-dependencies:
- dependency-name: sigstore/gh-action-sigstore-python
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.1.0 to 5.1.1.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v5.1.0...v5.1.1

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

This is the one from
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/


again, with an `if` condition added and multilines rewrapped. As
best as I can tell, this should work automagically, we don't need
to "sign up for" sigstore or create any certificates or keys; it
works by creating an ephemeral signing certificate bound to the
identity of whatever GitHub user the workflow runs as (proved by
OIDC), and signing with that.

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

The tarballs from current releases have these files in them, but
building with `build` does not include them. I don't know if the
previous maintainer was using setuptools-scm or something like
that, but this should ensure that appropriate files are included
in our new tarballs. I left out things like .gitattributes which
clearly shouldn't be in a release tarball.

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

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

This is based on
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#defining-a-workflow-job-environment
. It's the sample config from there, with versions updated and
our project name substituted in the appropriate places. I dropped
the publish-to-testpypi bit because of
https://github.com/pypa/packaging.python.org/issues/804

 , and left
the Github release part left out for now. We can add that later if
we like, but we never published releases to Github before, so it
doesn't seem required yet. I also tweaked the conditionals a bit
to avoid running the build job on forks and publish only tags
that start with 'v', as that's our convention for versions.

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

The latest incarnation of bumpversion is bump-my-version, which
considers .cfg configuration "deprecated" and wants it moved
to TOML, so here we go. We may as well move pytest config at
the same time as pytest has supported it for ages. We can drop
the "universal wheel" thing as that was about supporting Python
2 and 3 in the same wheel, and we don't support Python 2 any
more.

flake8 does not support pyproject.toml and it doesn't look like
you can specify aliases for setup.py there either, so we'll leave
those two in setup.cfg for now. Maybe in future we can get rid
of them.

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

It's much nicer to have the main repo as origin and your fork as
another remote you just push PR branches to. That way you don't
have to deal with resyncing the master branch of your fork all
the time.

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

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

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.0.0 to 5.1.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v5.0.0...v5.1.0

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

They were for an entirely different project.

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

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

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

Add missing classifiers for Python versions >= 3.9

This was lost when Travis stopped working, so our coveralls data
is frozen in 2021. This should get it working again using
https://github.com/marketplace/actions/coveralls-github-action


and allow coveralls to post comments on PRs.

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

This reverts commit 3addf1e3.

* `Iterator.next()`` has been replaced with `Iterator.__next__()`
* The `object.__unicode__()` method is not used anymore
* Default source encoding has changed from ASCII to UTF-8

As discussed upstream in
https://github.com/psf/requests/issues/4564

 , HTTP basic auth
usernames and passwords sent to requests as Python text strings
are encoded as latin1. This of course makes it impossible to
log in with a username or password containing characters not
represented in latin1, as the reporter of #315 found out.

To work around this rather old-fashioned default, let's intercept
string usernames and passwords and encode them as utf-8 before
sending them to requests.

Anyone dealing with a really old server that can't handle utf-8,
or something like that, can encode the username and password
appropriately and provide them as bytestrings.

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

I think we can just do this now Python 3.12 is stable.

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

Bump actions/setup-python from 4.8.0 to 5.0.0

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.8.0 to 5.0.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.8.0...v5.0.0

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bump actions/setup-python from 4.7.1 to 4.8.0

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.7.1 to 4.8.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.7.1...v4.8.0

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.7.0 to 4.7.1.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.7.0...v4.7.1

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Read the Docs has started requiring a .readthedocs.yaml configuration
file to be present in the repository in order to build the
documentation.

https://blog.readthedocs.com/migrate-configuration-v2/

According to the timeline we have until 2023-09-25 to migrate to the new
configuration file, but we've already had some builds fail during their
48-hour brownout on 2023-09-04.