Stop tracking registry accesses

[ro-tex]

PULL REQUEST

Overview

As we have high priority work that trumps DB performance tracking and optimisations, we wanted to have some quick wins before we park this effort. This PR provides those quick wins by removing registry tracking.

What's done here: Stop tracking registry accesses and drop all DB collections related to those.

Example for Visual Changes

Checklist

Review and complete the checklist to ensure that the PR is complete before assigned to an approver.

• All new methods or updated methods have clear docstrings
• Testing added or updated for new methods
• Verify if any changes impact the WebPortal Health Checks
• Approriate documentation updated
• Changelog file created

Issues Closed

[MSevey]

Is registry tracking useful information to have at some point? Are we just dropping it because it is currently impacting performance?

If so, we could disable the API but still keep the data collections right?

[ro-tex]

Is registry tracking useful information to have at some point? Are we just dropping it because it is currently impacting performance?

If so, we could disable the API but still keep the data collections right?

1. We don't have any indication that we have (or don't have) any performance issues. I keep repeating this but I want to make it clear that we're basing all of this on gut feeling and no data.
2. Personally, I find it positive to have this metric and I would have preferred to keep it. The fact is, though, that since its inception nobody has ever looked at it, so maybe I'm alone in my interest in it.
3. The data collection is the only action we perform on this data. The DB writes are the only thing that could potentially affect our performance.

In a perfect world, my preferred solution would be:

1. Keep gathering the metrics.
2. Replace our current strategy of one DB record per read/write with an aggregation - one record which holds the number of reads and write performed by a single user for each day. (Anon actions will be grouped together.) This will reduce the fidelity of the statistics (we'll only know the calls per day and not specific times during the day) but it will replace a relatively expensive record creation with a relatively inexpensive atomic increment of an integer field.
3. Run a batch job (either manually or in some form of compat code) that aggregates all existing statistics into such aggregations.

The reason not to go for that solution right now is that it's going to take longer (1 day of dev time + however long it takes to merge it) vs this near-instant solution (15-30 minutes + however long it takes to merge).

[peterjan]

LGTM