[CT-1368] New tracking event: Project ID

[iknox-fa]

We currently try to get the project ID for tracking purposes long before we actually load the project-- this causes a bunch of issues where we have to parse projects and such just to track the invocation. Since there's no benefit to this in terms of our analytics, this approach has been changed in this PR.

This ticket encompasses the work necessary to properly report the project ID at such a point that we actually load the project. This includes the work to update the internal analytics project to reflect the change in raw event data.

Specifically we need project_id as indicated here.

[jtcohen6]

This includes the work to update the internal analytics project to reflect the change in raw event data.

For simplicity, let's kick this out of scope for here, and open a new issue in our internal-analytics repo instead to track this as follow-up work: https:/dbt-labs/internal-analytics/issues/1402

[iknox-fa]

@jtcohen6 I was working on this, and I realized we already have the project id as part of the timing context. Would it make sense to source it from there as opposed to invoking another snowplow event?

[jtcohen6]

@iknox-fa Good find!

While that should work for the vast majority of cases, I think we want to guarantee that we have project_id tracked for 100% of invocations*. My sense is that, a programmatic invocation that passes in a manifest (and therefore doesn't call get_full_manifest) would never fire that event, and so we'd be missing it for that invocation. That's a pattern we might be pursuing with dbt-server.

*unless the user has opted out of tracking, of course

[iknox-fa]

Ah Ok that makes sense. A new event it is!

[jtcohen6]

Resolved by #7231!