feat: Async api

[dolfim-ibm]

Introduce the Async compute API

# sync (currently in place)
/v1alpha/convert/source
/v1alpha/convert/file

# launch async
/v1alpha/convert/source/async
/v1alpha/convert/file/async

# check status
/v1alpha/status/poll/{task_id}?wait=10
/v1alpha/status/ws/{task_id}

# get result
/v1alpha/result/{task_id}

Still TODO

• Definition of async api specs
• Implement first option with a local queue
• Websockets for push updates
• Deal with file return type (with return_as_file or multiple inputs)

Issue resolved by this Pull Request:
Resolves #51

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[Fogapod]

Suggested change

	if self.task_status in [TaskStatus.SUCCESS, TaskStatus.FAILURE]:
	return True
	return False
	return self.task_status in [TaskStatus.SUCCESS, TaskStatus.FAILURE]

[Fogapod]

I think ruff's SIM would suggest this fix

[Fogapod]

shouldnt this be a part of AsyncLocalOrchestrator API? too easy to make a mistake with 3 separate properties

[cau-git]

✨ Beautiful! Only small comments below.

[cau-git]

Maybe one could encapsulate these three members in a class that derives from asyncio.Queue to make it cleaner and less error prone to use.

[dolfim-ibm]

I think this and other refactoring will become more obvious once we implement the other compute engines (redis, etc)
The idea is also to have functionalities in some base class or objects.