Switch to stable Python ABI (abi3)

[HenningHolmDE]

Currently, the Python bindings are set up in a way, that we will have to build all binaries for the complete product of "supported architectures" and "supported python versions" for a package release.

By switching PyO3 to the stable Python ABI (abi3), this could be reduced to one build per architecture.

The advantage of building extension modules using the limited Python API is that package vendors only need to build and distribute a single copy (for each OS / architecture), and users can install it on all Python versions from the minimum version and up. The downside of this is that PyO3 can't use optimizations which rely on being compiled against a known exact Python version.

This somehow relates to #545, as increasing the minimum supported Python version would also be a way of reducing the number of build.

[duesee]

Can you say what would be necessary to switch PyO3 to the stable Python ABI?

[HenningHolmDE]

I know had the time to take a first look into it. Basically, adding the abi3-py38 (for a binary that would be compatible with all Python versions >= 3.8) feature for pyo3 would be the way to go.

However, currently, this breaks with serde-pyobject as they currently rely on a method that depends on an API function that has only stabilized with Python 3.10.

Off-hand, I see three ways of solving this:

1. increasing the minium required Python version for imap-codec to 3.10 (and then use abi3-py310 for pyo3)
2. contributing upstream changes to serde-pyobject to (at least optionally) remove relying on PyString::to_str
3. waiting for pythonize to support PyO3 0.22 and switch away from serde-pyobject

I would like going with 3, however, we cannot know if/when this happens. Thus, I would work on 2 now, because I really don't like the idea of forcing people to switch away from two otherwise still supported Python versions. Going with 1 would be the fallback plan if 2 turns out to be too much hassle (or the PR will not be merged/released in time).

[HenningHolmDE]

Building and testing the all supported Python versions on multiple platforms was already part of the CI template provided by maturin which was adopted in #576.

As the dependencies don't support switching to the stable ABI yet, it makes sense to postpone this step.