Re-evaluate and document WMArchive document structure

[amaltaro]

Impact of the new feature
WMArchive and WMAgent

Is your feature request related to a problem? Please describe.
It's been a couple of times that we had issues with WMArchive, like:

• documents too large
• publishing information that is not really useful for monitoring/debugging expected scenarios
• missing information; and so on

Further information in the following 2 tickets:

• Big json documents uploaded to WMArchive: Big jsons uploaded to WMArchive  #10879
• WMArchive monitoring down (again, large documents): WMArchive Grafana Monitoring Down / No Data #11960

Describe the solution you'd like
This is likely a meta-issue, but the initial activities to be carried out with this ticket are:

• document the current structure of WMArchive documents
• identify potential worst offender fields
• identify potential duplicate information
• share these with Computing Operations and define what we would like to keep in this monitoring.

Upon discussing the current schema, we would like have to (in future tickets):

• refactor the new schema
• add protections in the code, if needed (like document size)
• update WMArchive dashboard accordingly

Describe alternatives you've considered
As mentioned in the tickets above, MonIT limits the size of such documents to ~30MB.
CMSWEB and NGinx no longer have any limits (at some point it was limiting payload to 8MB).

Additional context
The tickets above have many insights.

[amaltaro]

On the use cases and important information for Ops, please refer to this comment made by Hasan:
#10879 (comment)

[vkuznet]

fine with me.

[amaltaro]

Sorry, I meant to close the pull request, not the issue itself. Reopening it.