x/telemetry: consolidate uploading and merging time horizons

[findleyr]

Right now, we have a nightly job that produces merged reports (those available at telemetry.go.dev/data) for the last 8 days. Yet the client may upload data for the last 21 days.

This has a few problems:

• 21 days is too ~short~long. ~We typically care about "28 day users", so should probably accept uploads up to 28 days old.~ we should limit to a shorter time period, for example 8 days
• We should produce merged summaries for all the uploads we get, even if they are older than 8 days.
• We should reject reports on the server if they are too old, so that we don't store uploads that won't ever be merged.

[rsc]

We're not getting user counts from this data, so I'm not sure why we care about 28-day-users. We'd only see something that old if someone used the go command three weeks ago and then not again until today. We do want to cap how long we need to wait for a given week's official record to stabilize, and 28 days seems very long.

It seems like we should flip in the other direction and reject uploads > 8 days old, at least if "old" is defined as today minus end-of-week. (For today minus start-of-week, 8 days old would really only be a 1-day-old cutoff.)

[findleyr]

Some responses inline below, but rejecting uploads > 8 days SGTM.

We're not getting user counts from this data, so I'm not sure why we care about 28-day-users.

We estimate the number of 28 day users by other means, and I thought it would be useful to be able to measure the experience of this population. Of course, there are various other biases that prevent us from accurately measuring the 28 day user population (for example, infrequent users are probably less likely to opt in to telemetry).

We do want to cap how long we need to wait for a given week's official record to stabilize

I don't actually have strong opinions about where we put the cutoff. 8 days sounds reasonable. Eyeballing recent data, it looks like we get >90% of reports within a week, so let's go with this. CC @fflewddur for awareness.

I did more investigation, and discovered that there are more reasons why older upload dates have relatively more "late data":

• We don't enforce a date cutoff when retrying an upload. So if gopls had tried to upload 2023-12-29.json and failed, I might have retried uploading it months later.
• https://go.dev/issue/63694 was not implemented until 2024-02, so before that change propagated to uploaders, we'd keep retrying reports that were invalid due to having an unrecognized program version.
• Before we had push tests and autodeployment of telemetry.go.dev (https://go.dev/issue/65165), it was not uncommon for it not to have the latest upload config, and therefore users with data for the most recent program version would have their reports rejected.

These three factors contribute to having much more "late" data in Dec 2023 / Jan 2024. Looking at recent data, this is significantly less of a problem now.

[rsc]

Sounds good, thanks.