This is for usage analytics in the product. Previously we were filtering
out the backend events, but as part of #52306 this was removed, because
I believed it shold not be there, as it was not part of the BuildCommonUsageConds
in the event_logs. However event_logs also add this condition directly
in the query string, which I did not notice.

Fixes MAU calculation in usage analytics in the product. 

Previously we were filtering out the backend events, but as part of
#52306 this was removed, because I believed it shold not be there, as it
was not part of the BuildCommonUsageConds in the event_logs. However
event_logs also add this condition directly in the query string, which I
did not notice.

Also, our timestamp calculation suffered from an edge case, where the
from time was not calculated right, e.g. on dates like
`2023-04-30T23:59:00Z`.

## Test plan

Tested locally and with customer data + added unit tests.

…52306)

Previously we used a different condition to calculate the MAU and other
stats in user analytics page. Now we use the same condition as we use
for pings. We also calculate everything using UTC now, so both should
give the same value.

## Test plan

Tested locally and also with data from Tinder. The new query for MAU
seems to be returning the correct data for us, I manually
cross-referenced the old query vs the new. Apart from the timezone
difference, the new query is more precise as in it filters the
sourcegraph-operator users and non-user events in the same way as we do
for the pings.

(cherry picked from commit 8d04aa1)

… pings for mau (#52608)

Previously we used a different condition to calculate the MAU and other
stats in user analytics page. Now we use the same condition as we use
for pings. We also calculate everything using UTC now, so both should
give the same value.

## Test plan

Tested locally and also with data from Tinder. The new query for MAU
seems to be returning the correct data for us, I manually
cross-referenced the old query vs the new. Apart from the timezone
difference, the new query is more precise as in it filters the
sourcegraph-operator users and non-user events in the same way as we do
for the pings.
 <br> Backport 8d04aa1 from #52306

Co-authored-by: Milan Freml <kopancek@users.noreply.github.com>

…52306)

Previously we used a different condition to calculate the MAU and other
stats in user analytics page. Now we use the same condition as we use
for pings. We also calculate everything using UTC now, so both should
give the same value.

## Test plan

Tested locally and also with data from Tinder. The new query for MAU
seems to be returning the correct data for us, I manually
cross-referenced the old query vs the new. Apart from the timezone
difference, the new query is more precise as in it filters the
sourcegraph-operator users and non-user events in the same way as we do
for the pings.

Fixes MAU calculation in usage analytics in the product. 

Previously we were filtering out the backend events, but as part of
#52306 this was removed, because I believed it shold not be there, as it
was not part of the BuildCommonUsageConds in the event_logs. However
event_logs also add this condition directly in the query string, which I
did not notice.

Also, our timestamp calculation suffered from an edge case, where the
from time was not calculated right, e.g. on dates like
`2023-04-30T23:59:00Z`.

## Test plan

Tested locally and with customer data + added unit tests.