refactor: use celebrate error handler

[mantariksh]

This PR uses the default celebrate error handler to handle validation errors instead of rolling our own generic one. This gives the client more informative error messages when validation fails. Logging was also improved to include the details of the validation error.

Why not use the celebrate error handler as a middleware?
Using isCelebrateError allows us to retain control over the error object before passing it to the celebrate error handler, which allows us to perform customised actions, e.g. logging. Moreover, I thought it was cleaner to use the celebrate error handler within the if (isCelebrateError) block rather than calling next, because that allows our error handler to retain control of the error object rather than calling next and trusting that the celebrate error handler will be called.

Before

After

[karrui]

I thought giving explicit Joi errors to the client is not a good idea, since it gives people who are calling our API programatically too much information about the shape of our API? But then again we are open source so....

[mantariksh]

there's nothing secret about our APIs, right? even if we weren't open source, a client could always deduce the required parameters from their network traffic. the point here is that as a general principle of API design, we should strive to give the client informative error messages when their requests fail. (if I'm interpreting the issue correctly haha, @liangyuanruo can correct me if I'm wrong?)

[liangyuanruo]

we should strive to give the client informative error messages when their requests fail.

I think the principle is not to return any information under the hood of the API interface. Telling the caller that a missing/incorrect/inconsistent parameter is OK, revealing internal database error messages is not.

[karrui]

🤩 lgtm