Here is some sort of notable changes:

1. response_content no longer support chunk_size since httpx does not support this. (encode/httpx#394)
2. gitlab clients are moved to client.py
3. 3 implementations of gitlab clients: gitlab.BaseGitlab abstract implementation that share common methods and store all docsrings, gitlab.Gitlab is sync implementation with httpx.Client, gitlab.AsyncGitlab is async implementation with httpx.AsyncClient.
4. on_http_error make nested since we can get coroutine and need to catch same error in awaiting response
5. RESTObject must be created (with create()), not initialized, since arguments could be coroutines, and need to be awaited, and __init__ does not support that interface
6. Everything should be returned, since it can be couroutin
7. every postprocess of response should be a function and be decorated with gitlab.utils.awaitable_postprocess, as it's done with _update_attrs and other edge cases
8. unit tests are run by pytest and run against async and sync client implementations
9. since unit tests are run with async gitlab, tests are required to be async, but fetching result is done through fixture that knows which client is used and return value if that's sync version or return await value if that's async version.
10. GitlabList support two versions of iteration
11. requests are completely removed

1. `response_content` no longer support `chunk_size` since `httpx` does not support
    this. ([encode/httpx#394](https://github.com/encode/httpx/issues/394))

I just noticed something: chunk_size is a configurable argument in several public methods (for blobs/snippet content, export download, etc) so it's possible people are using it and this would be a breaking change, right? Since you're replacing it with aiter_bytes and using chunks there, is there any way to preserve backward compatibility (I haven't checked the implementation)? Or wait for the upstream issue to resolve?

3. 3 implementations of gitlab clients: `gitlab.BaseGitlab` abstract implementation that share common methods and store all docsrings, `gitlab.Gitlab` is sync implementation with `httpx.Client`, `gitlab.AsyncGitlab` is async implementation with `httpx.AsyncClient`.
9. since unit tests are run with async gitlab, tests are required to be async, but fetching result is done through fixture that knows which client is used and `return value` if that's _sync_ version or `return await value` if that's `async` version.

That's really cool :)

@vishes-shell Thanks for all the work that you're doing!

People could have been using chunk_size, by providing a different requests instance, right?
(Which is also not supported anymore then?)

But we have nothing about this officially in the docs, so I would say we can solve this by mentioning it in the release notes. We anyway need to bump the version to 3.X.

@max-wittig I tried earlier and at least in some cases it can even be just:

project = gl.projects.get(1)
export = project.exports.create({})
dl = export.download(chunk_size=512)

From what I see in the current solution by @vishes-shell this would still work and wouldn't break anything, the argument would just be ignored by response_content(). But if anyone relies on chunk_size for some specific reason, it might break their behavior. I'm not sure of all the use cases but it seems useful especially for project exports: https://stackoverflow.com/questions/46205586/why-to-use-iter-content-and-chunk-size-in-python-requests/46205745