Analytics: Allow QAs to reliably verify analytics events sent during PR testing

[ilmotta]

Problem

While testing PRs, a QA may need to precisely know which analytics events were sent during their testing so that they can spot bugs or missed events. As of today this is hard or can be quite cumbersome because events are mixed with other events sent from devs during development or from other QAs testing PRs.

Implementation

The solution is to modify the centralized metrics implementation in status-go to allow the client to override the value referred to as UserID (a random UUID generated once per Status installation). For PR builds, using the environment variable COMMIT_HASH as the user ID provides a reliable and convenient way to filter analytics events by the commit hash, which is readily accessible in GitHub or CI jobs.

There's another benefit from solving this issue, which is that we want to eventually be able to track certain events using random user IDs. There are certain events where we don't care about the concept of a user or Status installation. For example, to the answer the question Which dApps are most used?.

Acceptance Criteria

• QA can pinpoint all events generated from any testing session.
• Outside CI environments, we should allow the developer to easily override the user ID as this can be useful during development. This can be achieved via a simple environment variable using the shadow-cljs machinery, just like we do with many other env vars.
• status-go should be changed to allow any custom UserID or fallback to the global value per installation. status-go should be agnostic of the value of the UserID, i.e. if the client sends banana, status-go should use that as the UserID.

[ilmotta]

cc @Samyoul @churik