[EPIC] Reevaluate Matomo Integration Post-N2T Cutover

[adambuttrick]

Following the N2T cut over, our current Matomo implementation resulted in a service degradation as a result of its connection to read-write options in our primary database relative to the high volume of resolution requests. We should thus evaluate what changes are needed to it to make this implementation fit for service or whether this functionality is better replaced by something else.

Potential options include:

• Separating Matomo read-write operations for logging into a different system such as RabbitMQ or Redis.
• Updating resolution logic to a specific/lower-level URL path, such that resolve requests are excluded from logging (and thus do not impact other read-write operations).
• Using OpenSearch for web analytics instead of Matomo.
• Implementing Matomo (or similar parsing) of Apache log analytics for a post-processed view vs. real-time analysis of EZID usage.

The ideal solution should:

• Minimize impact on overall service performance
• Provide similar analytics compared to our current Matomo implementation
• Be scalable to handle changes in traffic
• Be of comparable cost relative to our current logging and database infrastructure

[adambuttrick]

Research phase resulted in us deciding to use OpenSearch for our analytics instead.