feat: add "first" scope to get_player_scores

[minisbett]

Describe your changes

Adds the "first" scope for first-place scores to the API v1, as the API v2 does not contain any implementation for this kind of stuff yet.

Checklist

• I've manually tested my code

[tsunyoku]

ignoring the fact i see this becoming SHIT slow on maps with many scores, this needs consideration/ignoration for restricted users as their first places should not count

[minisbett]

ignoring the fact i see this becoming SHIT slow on maps with many scores, this needs consideration/ignoration for restricted users as their first places should not count

wait didnt I already add that to the query nvm

[tsunyoku]

i still think this would be a nice feature to get in, however i'm still concerned about performance - we should be using an intermediary table that is inserted to on score submission if score.rank == 1 with a script to back-fill this table. this is going to be quite involved as there's events which might trigger changes to these - right now i can only think of (un)restriction. @minisbett would you be happy to do something along these lines?

[cmyui]

Would it be possible to add this to the V2 API in a separate PR?

[minisbett]

Would it be possible to add this to the V2 API in a separate PR?

This would likely need a better implementation from scratch because it is super slow, eg. via a separate table or column

[cmyui]

Would it be possible to add this to the V2 API in a separate PR?

This would likely need a better implementation from scratch because it is super slow, eg. via a separate table or column

do you know the performance differences between this implementation & use of a window function? and do you have a sense of what sort of latency we're talking about with ~1mil+ scores? (or the general scalability?)

lastly, are you running bancho.py with the indices introduced last year?

[minisbett]

Would it be possible to add this to the V2 API in a separate PR?

This would likely need a better implementation from scratch because it is super slow, eg. via a separate table or column

do you know the performance differences between this implementation & use of a window function? and do you have a sense of what sort of latency we're talking about with ~1mil+ scores? (or the general scalability?)

lastly, are you running bancho.py with the indices introduced last year?

I no longer run bpy, but yes I used the indecies. With I believe 2-3 million scores the query took seconds on users, not sure how many. But it for sure was noticably the last thing on the website that loaded.