fix(labrinth): fix filtering not working unless breakdown set to same field

[penguinencounter]

fixes #6607 plus some similar cases

a few notes:

• project ID & dependent project ID work without changing their column enable logic
  • i did not check how they work, but they seem to work on prod so i didn't touch it
• pretty much all other fields needed a || !metrics.filter_by.<COLUMN>.is_empty() added
• user agent already had that, but was instead broken by not checking the correct thing when attaching the user agent data
• cargo sqlx prepare deleted a bunch of files. we've put that into its own commit so it can be dropped with git reset --hard or git rebase -i relatively easily if it's not meant to be there
  • feel free to force-push the PR as needed

and a screenshot of it doing the right thing:

[modrinth-bot]

Pull request changelog

App

Added

Changed

Deprecated

Removed

Fixed

Security

Website

Added

Changed

Deprecated

Removed

Fixed

Security

Hosting

Added

Changed

Deprecated

Removed

Fixed

Security

[penguinencounter]

would appreciate it if someone could look at this

[aecsocket]

Thanks for PR'ing a fix!

With the way the analytics endpoint was designed, if API users want to filter on a certain metric, they are supposed to also bucket by that metric explicitly. My rationale for this was that bucketing changes the response schema, whereas filtering will only remove certain items from arrays (but the schema of the items within the arrays stays the same). With this PR's behavior, if an API client chooses to filter by a field, they will also inherently break down by it. For example if I have 200 total downloads from X, Y, and Z, if I send a request to filter by only download sources X and Y, I'll get:

• { "downloads": 100, "source": "X" }
• { "downloads": 50, "source": "Y" }
• (the other 50 downloads from Z are excluded)

When in reality what I want is:

• { "downloads": 150 }
• (the other 50 downloads from Z are excluded)

This requires that we split out the fields we query by, from the fields that we aggregate/bucket by at the end when we actually reutrn the response. I can implement this on top of your PR.

Also re cargo sqlx prepare: you need to also prepare the test queries, so cargo sqlx prepare -- --tests

[penguinencounter]

you need to also prepare the test queries, so cargo sqlx prepare -- --tests

that should go in the docs :)

also, is the CI flaky? tests seem to be working fine on my computer. it could probably do with a re-run

@aecsocket is there anything else i need to do for this?

[aecsocket]

Good catch! I'll add it to the docs in this PR.

Also yes CI is quite flaky, ghcr is having a lot of issues with pulling images. I'll handle this though