Stamp caller attribution (rillUserEmail, rillServiceToken) on the Druid query context

[mpasa]

Stamps caller attribution on the query context of Druid SQL requests, similar to Imply Pivot's implyUserEmail/implyViewTitle, so queries can be attributed to users in Druid's query logs.

• The Druid driver now forwards two well-known keys from Statement.QueryAttributes to the query context: user_email → rillUserEmail and service_token → rillServiceToken.
• Both are optional and omitted from the request when unset; they do not affect query execution.
• Projects opt in via the metrics view's query_attributes, e.g.:

  query_attributes:
    user_email: '{{ if .user.email }}{{ .user.email }}{{ end }}'
    service_token: '{{ if and (not .user.email) .user.name }}{{ .user.name }}{{ end }}'

• Adds unit tests for the driver's query context serialization (the druidsqldriver package previously had none).

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

---

Developed in collaboration with Claude Code

[nishantmonu51]

@codex: review

[nishantmonu51]

@pjain1 : Can you help review this one ?

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: b91a148f56

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[pjain1]

Instead of adding custom keys here, I would rather pass in key/values from stmt.QueryAttributes as it is so any arbitrary attributes you define in metrics view will be passed as it in Druid context. But this would either need a custom marshaller for DruidQueryContext or changing the struct to just a map.