feat: add config to make error messages configurable

[stevenpyzhang]

Description

This PR adds a ksql.server.error.messages config which takes a class that implements the ErrorMessages interface. It uses the ErrorMessages class in certain places to return more targeted error messages (such as linking to documentation in the error message when the user runs into ACLs related errors)

In the future, more responses can be changed to use methods from the class that's plugged in through the server configs.

Testing done

Unit tests
Made my own ErrorMEssagesImpl and specified it in the config

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[big-andy-coates]

Thanks @stevenpyzhang

I understand the motivation for this, however this introduces a new public API that we'll need to maintain compatibility with (ideally) moving forward. As such, we should consider is this the right interface to expose? . I would say not. I think this needs a little bit more thought.

At the moment the interface allows the actual HTTP status code to be customised, which could result in some strange behaviours if, for example, an implementation returned a success code where an error code was needed. Is there a need to be able to change the status code? I understand from the description its really only the error message we want to customize.

Might we not be better creating a new ErrorMessages interface or similar, more targeted towards what we actually want to achieve? Such an interface could then be accepted by an Errors class and used to customise the message in the response.

Let me know if the requirements or your plans cover more than just message text.

Add me back in as a reviewer if you want me to review again.

[stevenpyzhang]

Might we not be better creating a new ErrorMessages interface or similar, more targeted towards what we actually want to achieve? Such an interface could then be accepted by an Errors class and used to customise the message in the response.

Went with this. The scope for this should be just the error message so I agree, the previous approach was a bit too heavy handed with potentially changing up error codes.

[big-andy-coates]

Thanks @stevenpyzhang

Missing unit tests for the changes to Errors and the pattern of passing an instance of Errors to a static method of Errors is very questionable. Make it a member function!

Otherwise LGTM.

[big-andy-coates]

Missing unit test for this method.

[stevenpyzhang]

added

[big-andy-coates]

Missing unit test for this method.

[stevenpyzhang]

added