Add usage analytics tracking

[liam-sbhoo]

Change Description

Add minimal usage analytics tracking:

• tabpfn_client extracts basic usage info based on the caller's environment, and sends this info in request headers.
• tracking non-privacy intrusive metadata, see "tabpfn_common_utils/usage_analytics/analytics_definition.py"

  ANALYTICS_TO_TRACK = [
    ("X-Unique-Call-Id", get_unique_call_id),
    ("X-Python-Version", get_python_version),
    ("X-Calling-Class", get_calling_class),
    ("X-Module-Name", None),  # Value provided by AnalyticsHttpClient 
  ]

Try to be precise. You can additionally add comments to your PR, this might help the reviewer a lot.

If you used new dependencies: Did you add them to requirements.txt?

Who did you ping on Mattermost to review your PR? Please ping that person again whenever you are ready for another review.

Breaking changes

If you made any breaking changes, please update the version number.
Breaking changes are totally fine, we just need to make sure to keep the users informed and the server in sync.

Does this PR break the API? If so, what is the corresponding server commit?

Does this PR break the user interface? If so, why?

---

Please do not mark comments/conversations as resolved unless you are the assigned reviewer. This helps maintain clarity during the review process.

[CLAassistant]

All committers have signed the CLA.

[Jabb0]

Are you sure there is no way of getting the module name programmatically?

[liam-sbhoo]

At least not robustly, in my opinion.
My rationale: tabpfn-extensions or wrappers built by users can create arbitrarily deep call stack. So I thought it'd be easier to let the wrapper, e.g. tabpfn-extensions, set the module name explicitly.

[Jabb0]

I see. I was hoping there is a better way to get the module name than iterating the call stack.

[Jabb0]

You are not expecting this to change during service run. It should be ONLY in the constructor of ServiceClient and then stored as a private member.

[liam-sbhoo]

ServiceClient is a singleton class, hence we don't have an constructor as per say.
I'm also wondering if there's a better design for classes like ServiceClient

[Jabb0]

There should be. Singletons are to be handled with cautions, because as for global variables, they can be changed in multiple places and thus introduce side-effects. Also they are harder to test, because dependency injection does not work.

I'd need to think more about this here.

But one way would be to create a client instance. And then this instance needs to be passed when calls are made.

[Jabb0]

should be private btw.

[Jabb0]

Tests missing.