* `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.

Bump actions/checkout from 3 to 4

Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3...v4

)

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

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

Bump actions/setup-python from 4.6.1 to 4.7.0

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.6.1 to 4.7.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.6.1...v4.7.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>

Bump actions/setup-python from 4.6.0 to 4.6.1

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.6.0 to 4.6.1.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.6.0...v4.6.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>

Mark tests as requiring setuptools in tox.ini and setup.py

test_client.py uses pkg_resources. That's part of setuptools,
not Python. Per
https://docs.python.org/3.12/whatsnew/3.12.html#removed

 , it
was previously included by default in venv environments, but no
longer is from 3.12 onwards, so we need to explicitly require
setuptools to ensure it's available.

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

Bump actions/setup-python from 4.5.0 to 4.6.0

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4.5.0 to 4.6.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4.5.0...v4.6.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>

API calls: raise original exception when retries exhausted

This is an alternative approach to solve the problem identified
in #279 . When doing API calls with `retry_on_error` set to
true (the default), if the call fails after all retries are
exhausted, we raise our own `MaximumRetriesExceeded` exception,
which tells you nothing about what actually went wrong, just
that we exhausted the retry count. It seems much more useful
to raise an exception with information about why the connection
is failing.

This changes that behaviour so that, on most paths, we would
raise an appropriate exception from requests (either the one
we caught, or an HTTPError via `raise_for_status`) if we exhaust
the retry count. Only if we fail due to database lag would we
still raise `MaximumRetriesExceeded` (because there isn't really
an underlying exception we can handily raise in that case).

Note that it was already possible to hit
`stream.raise_for_status()` before this change, if the status
code was outside the 500 range, so in theory callers should
already be prepared for that. It was not possible to get a
`requests.exceptions.ConnectionError` or
`requests.exceptions.Timeout` with `retry_on_error` true, though,
so this is genuinely a behaviour change on that front.

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

Handle page protection having no expiry (#290)

Issue #290 gives an example of a wiki with protected pages whose
protection definitions have no 'expiry' key at all. This seems
strange and, on a quick through the mediawiki code, difficult
to achieve, but since there's a live site out there that does it,
and mediawiki *does* seem to have at least some code to handle
such cases (e.g. how the expiry shows as 'indefinite' in the
page information), let's handle it too, by representing this as
None.

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

Add/Update some documentation

Document how to connect using a proxy

Add mime to imageinfo

Add move_subpages, ignore_warnings to page.move

Improve and fix Site.expandtemplates