[Proposal] 131 - express error-response API in terms of error codes

[Keith W]

Whilst working on eliminating the Kafka internal classes from the Kroxylicious public Filter/Router API it has become clear that the original proposal https://github.com/kroxylicious/design/blob/main/proposals/116-kafka-api-migration.md didn't fully appreciate the issues that the ApiException.

The ApiException appears in two places in the API:

• RequestFilterResultBuilder.errorResponse(RequestHeaderData, ApiMessage, ApiException)
• RouterContext.respondWithError(RequestHeaderData, ApiMessage, ApiException)

Vendoring ApiException would mean also vendoring its 156 subclasses. This would substantially increase the Kroxylicious public API surface and would tie us to Kafka's own exceptions.

https://github.com/kroxylicious/design/pull/131 considers a different approach.

Eliminate the ApiException from the public API and instead have the caller speak in terms of errorCodes and errorMessages.   This not only avoids the nasty vendoring problem, it gives us a more consistent API (Data objects use errorCode/errorMessages and the Metadata API uses errorCodes).