Fix sample rate calculator estimated traffic overshoot when date range is longer than site stats range

[apata]

Changes

This PR fixes how we estimate traffic to calculate the sample rate for the query.

There were two issues. The first was noticed by a user, the second by me when I was fixing the first.

1) Overestimating events to scan for longer queries

We were overestimating the events the query would scan when the query start date was significantly before site stats start date, e.g. date range is 1970 to 2026, but stats actually start on 2025.

Previously, the calculator when run for this query would have estimated traffic to be 56 years worth of last month's average daily traffic.

Now, the calculator takes into account that stats start from 2025, so for this query, the estimated traffic is 1 years worth of last month's average daily traffic.

2) Underestimating events to scan for newer sites with high ingestion rate

We were underestimating the events the query would scan when the site's ingest counters have accumulated over less than 30 days.

Previously, a query for a new site ingesting 10M events per day for 3 days would not have been sampled, but a query for an older site ingesting 10M events per day for the last 30 days would have been. Expected is that both are sampled with the same rate.

Tests

• Automated tests have been added

Changelog

• Entry has been added to changelog

Documentation

• This change does not need a documentation update

Dark mode

• This PR does not change the UI

[apata]

There's one more buggy scenario that I noticed: when the end date is far in the future, we'll overestimate events to scan and use an inappropriate sample rate.

A query from the year 2026 to the year 2100 would estimate events to scan to be ~75 years worth of last 30 month average event count, while the actual events to scan would be half a year's worth, up to now. Can't have events in the future.