This way we do not recompute/bruteforce twice any hash. We check the cache first and
accoring to the configuration, we see if we processed to the bruteforcing or not.

added some visuals for our readme,

Closes #13

See merge request !11

pushed to remote the hash checker result files

Closes #12

See merge request !10

Impl of the teacher's testing program integration.

Closes #11

See merge request !9

The idea of our implementation is to add a proxy between the backend and the teacher's program since
our backend does not offer a websocket based API.
This proxy's duty is to offer such API and then forward the incoming requests from the tester
program to our backend.
We had to tweak the backend to add a couple new endpoints for the tester and also we had to tweak
the worker to accept range based hash submission (begin charset bound, end charset bound).
This does not break retrocompability and leave the legacy code intact !

TODO;
We should next consider adding new tests to keep the coverage reasonable.

updated readme & added licence

Closes #10

See merge request !8

updated our pipline cmds and our readme coverage anchor

Closes #9

See merge request !7

Resolve "Add tests & coverage badges"

Closes #6

See merge request !6

Resolve "Enhance frontend UI/UX"

Closes #7

See merge request !5

Add export functionality for our inputs/outputs of our md5raids.

Closes #8

See merge request !4

added an automatic scaler for our workers,

Closes #4

See merge request !3

first-impl-backend-frontend-worker-pipeline

Closes #1, #2, and #3

See merge request !2

add an export button to export the inputs and the outputs of automatic hash generation and submitting, make the input and
  output files be seperate this way the teacher can inject the inputs to his program and check if the outputs match

Updated the UI and the backend to send to the end user the scaler config information, this way the user can predict the assumed behavior

per worker rather then scale if pending_jobs_count > 5)