Replace `requests` with `httpx`

[ammar92]

Is your feature request related to a problem? Please describe. I propose to replace requests with httpx for the following reasons:

• Async support; in longer term could improve performance e.g. in multiple requests such as health pages or prefetching
• Connection pooling (by default); which in our case could lead clients to be more efficient in usage of connections and possibly improve performance
• Better compatibility with (newer) web standards; it's designed with an emphasis on keeping up with the latest web standards (see also example in additional context below)
• Unlike requests which only supports response streaming, httpx also supports request streaming, which can be beneficial when handling larger file (uploads), e.g. saving larger files to bytes in chunks
• Built-in support for WebSocket; no use case for this (yet), but nice to have
• Supports HTTP/2 natively
• The httpx.Client conveniently handles base URLs, which in our case results in less boiler plate code when handling base URLs from settings

Describe the solution you'd like For the transition I suggest to do the following:

• Replace requests with httpx dependency for each module
  • Should not be too complexe since, given the high compatibility between the two packages
  • Replace requests.Session objects with httpx.Client
• Make sure the tests pass
  • In some of the tests we mock requests output, this should be done carefully when replacing that package

Additional context This came to my mind because of the extra boilerplate code to handle base URLs. Also in an earlier issue where we actually used httpx, it blocked a GET request including a body, which is a good thing because it means httpx practices (modern) standards more strictly.

[dekkers]

Httpx seems to be the better library nowadays and given that it's mostly compatible it should indeed not be a lot of effort to switch. We would have to test it carefully, because as far as I know we have lot of requests between services that are not covered by integration tests.

[underdarknl]

Agreed, when the dust around 1.14 / reports settles we should have a look at this. Preferably at the beginning of a sprint, right after a release so we can test the changes for two sprints.

[stephanie0x00]

Checklist for QA:

• [x] I have checked out this branch, and successfully ran a fresh make reset.
• [x] I confirmed that there are no unintended functional regressions in this branch:
  • [x] I have managed to pass the onboarding flow
  • [x] Objects and Findings are created properly
  • [x] Tasks are created and completed properly
• [x] I confirmed that the PR's advertised feature or hotfix works as intended.

What works:

Looks good! No error messages are shown and the logs look fine too. Ready for merge.

What doesn't work:

n/a

Bug or feature?:

n/a