Refactor structs guarded by mutexes

[guicassolato]

Most structs guarding data behind a Mutex/RWMutex such as authorization.OPA, identity.APIKey and identity.MTLS are not clear about what fields are guarded in the way they are declared and handled, requiring one who reads the code to dive into the details of each implementation to identify the critical sections.

By not clearly delimiting the critical sections, not only it compromises the immediate readability of the code but it imposes a risk for long-term maintainability of it. One who touches the code could easily overlook data fields meant to be handled in a critical section and inadvertently jeopardize the entire concurrency control.

Here are a couple patterns to improve immediate readability and long-term security/maintainability of the implementations for critical sections and concurrency control:

1. Preferred approach - All data handled in a critical section encapsulated in a separate struct, which exposes the necessary functions to handle the data to the caller, ensuring proper and abstracted concurrency control. This is the approach adopted in controller.StatusReportMap.
2. Alternative immediate approach - In the cases where the above is not immediately feasible, adopting some convention in the sense of highlighting the data fields associated with the critical section, e.g. declaring the fields in a block with the declaration of the mutex itself. This is a not ideal regarding long-term security/maintainability, but can deliver immediate improved readability.

cc @alexsnaps