* simple user creation
* block user
* unblock user
* get basic info about user
* get groups
* add groups
* remove groups
* set groups (get current ones and add/remove what is needed)

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.

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