Migrate autograder to use Javalin

[ThanGerlek]

Migrate the Server class to use the Javalin web framework instead of SparkJava. The logic transfers over fairly neatly but with a few changes noted below. Closes #443.

Significant changes

• Spark's Request and Response objects are both replaced with a single Context object
• Handler methods (previously Route) can no longer have return values
• No halt() method exists
• ctx.json(responseObject) automatically serializes and sets the response body (using our Serializer class), and ctx.bodyAsClass(ClassName.class) deserializes the request
• Error responses are now handled via thrown Exceptions (ctx.status() works, but this is the standard to simplify/standardize/DRYify code). As such, various additional Exception classes have been added, largely corresponding to HTTP codes

Dependencies

• Remove Server's dependency on Controller classes #479
• Test server endpoints #483 (which also depends on 479) is not a dependency, but it adds relevant unit tests, so it is recommended that it be merged in before this

[ThanGerlek]

Still to do: unit and integration tests

EDIT: Unit tests are in #483.

[frozenfrank]

Does this work properly even when the server is paused on a breakpoint, as if in a debug session?

My first guess is that the automatic pings would also be paused if the server is paused, which defeats the purpose of this timeout.

[ThanGerlek]

I did some testing, and you're right--that's something we'll have to be aware of when debugging. Fortunately it seems like the only time it affects anything is if the server hits a breakpoint partway through grading a submission, which probably won't happen often. Either way, the original problem was WS timing out when unit tests take a long time to run, and it does fix that.

[frozenfrank]

Is there a way to also increase the timeout to a large value? That would be helpful for any server debugging, should that arise. Even if we, the autograder team, don't typically use this much, the students will need an increased timeout limit because they will be extensively debugging their servers.

[webecke]

But students won't need it on the Autograder, will they? They're not debugging the code as its submitting to the autograder, the debug on their local machine, right?

[ThanGerlek]

I couldn't find one, and this Javalin issue from last month seems to suggest there isn't one. So I don't think so but I'm not sure 🤷

[frozenfrank]

But students won't need it on the Autograder, will they? They're not debugging the code as its submitting to the autograder, the debug on their local machine, right?

@webecke My bad, let me clarify. I didn't mean to suggest that the students will be debugging on the AutoGrader. I meant to make reference to future semester where they will be building their chess projects using a version of Javalin. At that point they will be debugging code and stepping through websocket endpoints, and they will need to be able to keep their websocket connections alive.

I couldn't find one, and javalin/javalin#2329 from last month seems to suggest there isn't one.

@ThanGerlek Thanks for referring to that Javaline issue. I just commented on it with my research on the WS timeout issue. From what I can tell without having actually used Javalin myself, the feature doesn't yet exist.

I see this as a symptom of using a premature product which is not yet fully featured. We should keep a list of this and any other weird things we discover about the platform. These kinds of details obviously don't make the entire decision, but the quantity and frequency and severity of multiple of them can influence our decision to look for a different platform as well.

We should take this is a reminder that this is just a community project. Upon reviewing the recently merged PRs, I see a total of 4 substantial PRs in the last 3 months. The professors suggested that this could be a good tool, but it may not be. We should keep our eyes and options open to switching to a different platform which may be better than Javalin.