Replaced the dynamic JSON string construction with a direct dictionary
definition for namespaces.

This commit refactors the codebase to consistently use Python 3.6
f-strings for string concatenation and interpolation.

BREAKING CHANGE: This update increases the minimum required Python
version from 3.5 to 3.6. Python 3.5 reached end-of-life in September
2020 (~4 years ago) and has been dropped from most distributions, so the
impact on users should be minimal.

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.

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>

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

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>

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>

It seems that pytest-cov does not collect any coverage without
this file.

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

`clientlogin()` does `self.require(1, 27)`, which needs the site
instance's `version` attribute to be set, but this is usually
done by `site_init()`, which is mocked out in the tests. We can
fix the problem by just manually setting a sufficiently high
version in the tests.

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

Allow specifying `uselang` with `Page.revisions()` and
`Site.usercontributions()` to get localized parsed comments with
`prop=parsedcomment`.

Breaking change: Change the `Site.ask()` method to produce less nested
output. Basically, change `yield {title: answer}` to `yield answer`. The
title is included in the answer object after all.

The rvexpandtemplates parameter has been removed, but we can use
action=expandtemplates instead.

This fixes tests not being added to the source package.