[WIP] To async or not to async

[lucagobbi]

Description

This PR removes blocking code from async route definitions, which is currently blocking the event loop. Async code is usually introduced to improve performance in IO bound scenarios like network calls, reading/writing files, etc. We have a bunch of those cases throughout the entire codebase, this is just a starting point.

It's important to note that not all code should be made asynchronous for the sake of readability and practicality, we should be mindful of how synchronous and asynchronous code are handled within our FastAPI application, 'cause simply putting async before any method is not a solution.

Related to issue #945

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

[pieroit]

@lucagobbi thanks and agree on not exaggerating on the async/await.
Let's put it only where it is necessary; also, if it comes to a decision of:

• scalability vs devx

We want devx every time. The point of the Cat is easy customization and easy go online, it has to be fun and a learning experience. We don't want devs to spend time on async/await and coroutines and event loops as only a few people (to my knowledge only you and @Pingdred) spent time on that issue.

Please remeber: EASY EASY EASY
Easy primitives, easy devx, fun is priority over performance.

Moreover, technology to scale nodes horizontally has become mainstream and if companies / enterprises want to scale, let them buy the machines.