We need some kind of *opt-in* Telemetry

# Context

We're currently trying to determine:

- whether Mjölnir should attempt to backoff-and-retry in case of connection timeout;
- if so, how long it should retry.

The risk of picking wrong values is that Mjölnir could end up contributing to overloading a server that is already too loaded.

I believe that we need some kind of data on how often these timeouts happen and, if we implement backoff-and-retry, how many connections this adds. The only way to get this kind of information is to have some form of Telemetry.

# General idea

- Add a configuration option to turn on Telemetry and specify a Telemetry server. If unset (e.g. by default), Telemetry is off.
- Add some kind of linter to ensure that Telemetry remains unset by default?
- Use a Telemetry protocol/server such as e.g. Sentry to store performance data.
- Whenever we add a Telemetry probe, reviewers are in charge of checking that they do not contain sensitive data (performance numbers should be safe).

The issue identifies no files, tests, or entry points; begin by locating the configuration and connection-timeout handling in the TypeScript repository. Done means telemetry is explicitly opt-in and remains off when unset, while collected performance data excludes sensitive information.

Written by the indexing model from the issue text.