How might we improve DCAR/frontend logging?

As a result of mobbing session with @marjisound, @arelra & @JamieB-gu we came up with the following tasks:

#### small

- Structured logging
- router log message value is a string (unstructured) with several useful information, can we make it structured?
- investigate if some of the fields could get removed e.g. event.original
- why do we have inconsistent fields e.g. level & log_level
- too many info logs in frontend that we may not need (it's making it noisy)
- look into frontend to find opportunities to remove some of the info logs or change level to debug
- a dashboard that shows a count of all log levels on the Frontend apps [here](https://logs.gutools.co.uk/s/dotcom/app/dashboards#/view/8e4f03c4-c0e0-5460-8679-5d6254f8f696?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-1h,to:now)))
- We don't need to have both `Rendered page` & `Page render time`. Can we remove the render time one, and adding the render time as a new field in the `Rendered page` log
- align the casing in the dcr log fields
- Add upstream service name in router errors

#### medium

- Can we have a specific view in kibana without the noise in the logs (devx fields that we don't care about)
- Can we find out if a dcr request has timed out and log it
- Investigate [canonical log lines](https://stripe.com/blog/canonical-log-lines)
- Adding logs to data lake?

#### large

- Using ErrorCode rather than string description of the error. e.g. WARN001, ERROR002
- Can we make the logs functional?