Unified logging strategy

[BenedictHomuth]

The problem

For now our logging in the backend is kind of a mess.

Sometimes, we log only on the service layer, sometimes already in the API layer, and sometimes on both.
This seems weird to me.

We should investigate if this behavior is intended.

If not, we should employ a unified logging strategy.
This could then include:

• logging at one place
• logging at all the places
• logging at different but not all levels for different reasons

--> However at least in a way that does not seem as random as of today. (maybe even document the why and when 😃)

[liza-kl]

I had a look at the codebase yesterday and noted the following things:

• We mainly log in the services and api layer
  The "deeper" services layer logs if the function does not return an error that the api layer can access or if the function iterates. This is probably more convenient than directly returning an error and breaking out of the loop.
• Another reason might be that the error types InternalError (and NotFoundError) are structs (see server/src/common/error.go), while other types provide a function which is then thrown with Throw().

You could alleviate this "randomness" by returning errors on the services level, rewriting InternalError and NotFoundError to functions, and then logging everything on the API level.
-> This, however, could lead to more inflexibility regarding logging. A discussion about "structured logging" might be helpful here.

[SelinaBuff]

It’s best if you all come together again, maybe with @BenedictHomuth before he moves on, and make a suitable decision.
@liza-kl @mateo-ivc