New architecture for judger

[ZTL-UwU]

As vanilla WebSocket is so bad to use in TypeScript, I think we should not actually use it.
To solve this, I now have two solutions. Which I personally prefer the second one.

1. Use node.js to develop the Judger instead of rust.

   • We can then use Socket.io, which makes the Judge Leader's development much easier, and the code look way much better because we've already used Socket.io between the Judge Leader and the Judger port, it's odd to have both Socket.io and Vanilla WebSocket together.
   • The bad thing about this solution is that the Judger might be a little bit harder to write because both the Judger Core and the Sandbox are written in Rust.

2. Use HTTP. CURRENT ARCH
   We can set up an HTTP server on the judger.
   Here is the way.

   1. Judger initialization: POST requests the Judge Leader's /api/judger, send its max judging max thread and server port.

      {
          "max_thread": 4,
          "port": 4000
      }

   2. The Judge Leader keeps the status of all the Judgers' statuses.
   3. When the Judge Leader receives a task, it'll find randomly find an available Judger and send the task to it using POST the Judger's /api/task, send:
      • Problem ID
      • URL to the test data in a Data Server
      • Code language
      • Time and memory limit
      • The code
   4. When done, the Judger sends DELET to the Judge Leader's /api/task to finish the task.

I personally prefer the second solution.

[ZTL-UwU]

@szdytom