Deduplicate dependency and packaging tooling

[Ichimonji10]

PEP 518 and PEP 517 define how to install and execute a build system for Python packages, respectively. Of interest to developers is that they define a pyproject.toml file. For a project that depends upon setuptools, its complete contents would be as follows:

[build-system]
requires = ["setuptools", "wheel"]  # PEP 508 specifications.

When the build frontend executes, it will install and invoke setuptools, which will look for files like setup.py.

Projects aren't required to use setuptools to build packages, though. They could also choose a backend like poetry. If poetry was used, the pyproject.toml file would be significantly longer, and no setup.* files would exist.

This project appears to make use of both setuptools and poetry. This is confusing to me, and probably other humans as well. It's also a source of bugs. Consider:

• pyproject.toml depends upon prometheus-client = "^0.7.1"
• setup.py depends upon prometheus_client==0.7.1

Both the project name and the version specifiers differ! What's up with that? And:

• setup.py lists two dependencies
• pyproject.toml lists eleven dependencies

What's up with that? And more. There's more.

Could this project settle on a single build system? That would make life easier for humans, who only have to learn a single build system, and would provide a smaller surface area for bugs, as only one build system would need to be maintained, and two build systems wouldn't need to be kept in sync.

[Ichimonji10]

98 re-introduces setup.py so that existing RPM packaging tooling can be used with as little disruption as possible. IMO this issue should be re-opened.