Inconsistent use of HTTP Status types after TUMLiveContext check

[MatthiasReumann]

Is your feature request related to a problem? Please describe. If the TUMLiveContext doesn't exist, sometimes http.StatusInternalServerError is returned and on other occasions http.StatusNotFound.

One Example: api/chat.go -> getMessages(...) and tools/middlewares.go -> InitStream(...) InitStream being the middleware which is executed before getMessages.

Describe the solution you'd like Consistent use of http.StatusNotFound. Sometimes the check in the handler itself (as seen above) is not necessary. In that cases the if !exists { ... } might also be removed.

[joschahenningsen]

TUMLiveContext should always exist (because it's added in a middleware that is attached to every request), therefore not having the context is an inconsistent application state and should be indicated with a 500 error.

Since the context is always present (unless we're in requests for static files or we did something very wrong) we might want to use c.MustGet https://pkg.go.dev/github.com/gin-gonic/gin#Context.MustGet and avoid checking if it was found.