--> copy/paste from #16

Je pense qu'on peut améliorer la structure du projet:
Pour l'instant il y a deux modules:

• redis_interface: qui représente les interactions avec le monde
• parser: qui parse

Je trouve que le module parser est super car il est totalement self-contained. Il prend des strings et les parse en structures de données que tu veux, il fait son taff et juste sont taff..

Par contre redis_interface fait un peu tout... Genre dans worker/worker/redis_interface/challenges.py, la fonction retrieve_category_info n'a aucun rapport avec Redis, et en plus elle ne fait pas l'interface avec le système et redis mais plutôt entre le système et Rootme. Alors je sais bien que c'est une fonction qui n'est utilisée que dans ce fichier (d'ailleurs les fonctions non exportées devraient être préfixées d'un _), mais ca correspond quand même pas à ce qu'on attend intuitivement d'une "interface vers redis".

Je pense que l'actuel redis_interface peut être split en 3 modules, ça va t'aider à avoir une architecture plus claire, écrire tes tests plus facilement et potentiellement de pouvoir faire des refactoring plus facilement.
redis_interface pourrait devenir:

• redis_interface: garder le module, mais y mettre QUE des fonctions qui font l'interface entre ton système et redis. (en gros ca serait un adapter, dans le "port and adapter pattern")
• root_me_interface: Les fonction qui concernent l'interfacage avec rootme, en gros ca serait toujours un appel au HTTP_client + parse et on retourne la valeur. (comme ca ca se teste super simplement)
• ??? le nom reste à définir (peut être juste worker) qui établit le workflow de ton worker. Genre par exemple, quand on a un ordre d'update, d'abord on uitilise l'interface redis pour récup le timestamp, on check si la resource doit être update, si elle doit être update, on utilise l'interface rootme pour recup les infos, puis on met des données dans redis en utilisant l'interface redis. C'est un exemple de "workflow" qui serait contenu dans ce module

C'est juste une proposition, mais avec ça, juste en lisant la 3ème classe on peut comprendre ce que fait concrètement ton worker, et en lisant les interfaces, on peut comprendre COMMENT il fait

Use discord context to get author of "!flush" command

Example : AK丶

red(f'Error with {user} user --> last chall: {last}\n')

--> error with username not dict

Use i18n

We might want to display something when r.status_code != 200 ??

Default has to be en

Do not forget to add "rootme_url" field for every endpoints with the url used to make a request on RootMe website as value for this field

Example
[!] Error with {'id_discord_server': <censored>, 'rootme_username': '<censored>', 'last_challenge_solve': 'PHP - Register globals'} user --> last chall: PHP - Register globals

• check redis keys content
• check redis stream order for duplicates (might be in API)

Need to update last_challenge with new language on lang update

--> Trigger errors in cron tasks with alst challenge solve for a user

Add footer like in !info for all embed messages

show github repository link with small description

API has en/fr/de/es options for lang

Groupe challenges solved by catégories when using !diff or !diff_with commands

Add a reset command that can only be used by the server owner to clean all the data in database for rootme users

Check if !lang is already the current language