Controller logging improvements

[mdemirhan]

Expected Behavior

Controller code was recently migrated to use a structured logging library. A basic structure was added to the logs as part of this work - revision, configuration, route names & namespaces are uplifted from the message into its own key value pairs. The advantage of such uplifting is that such fields can act as a filters to search within messages.

However; a detailed analysis on the current logs needs to be done and more structure to the logs should be added as appropriate. Below is a proposed guideline by @grantr to determine if something should be kept in the log message vs should be a separate key/value pair in the logs:

If a field can act as a filter key to group messages, it should be a structured log field. If a field's searchability will lead to confusion (for example, if it tends to be parsed incorrectly or is easily confused with a different field) then it should not be a structured log field. If a field's key is dynamic with high cardinality, then it should be interpolated (though in this case, the dynamic key should likely be a value itself).