Streamline error handling in kuksa.v1 proto

In case errors occur, we try to give as much details as possible. For errors related tot he VSS model itself, we always try to return eoor information (codes/reasons) in line with VISS (see here: https://www.w3.org/TR/viss2-transport/#status-codes)

We are not always successful with this, as for some calls we return custom errors, other calls lacke them, sometimes we fall back to generic GRPC errors without (being able to) setting the correct error information.

This should be streamlined, so that you can expect errors to be returned in the same way, and where applicable error codes aligned to VISS

I see two parts of this problems. The first is how errors are returned to the actual gRPC-client. There we can affect what is returned in those cases where the RPC reaches the "business logic" on the server side, for example if token validation fails. But then we can have another level of abstraction, and that is what is returned to users of "official KUKSA clients", like the databroker-cli or kuksa-client. It would be possible in the client to match Proto error codes (see https://grpc.github.io/grpc/cpp/md_doc_statuscodes.html) to something else. Like if the response provided by the server cannot be parsed, should we then just show the gRPC error "INTERNAL", or should we on client side try to translate it to for example "406 (Not Acceptable)". Especially if we want to continue to support KUKSA.val Server it would be preferable to have a consistent error handling for both Databroker and Server, so that a client can switch between them. That means that the client always must return a "KUKSA error code" to the caller, either by taking one embedded in the gRPC (or websocket) error message, or if not present by mapping the transport layer error message (gRPC/Websocket) to a reasonable "KUKSA error code". For troubleshooting it is off course good to keep and present the gRPC/websocket error as well.

eclipse / kuksa.val

Streamline error handling in kuksa.v1 proto #594