Cache problem fix

[GramThanos]

The caching of the API that returns the scoreboard does not take into that the given parameters may have changed.

[ColdHeat]

I actually have a need for the function you created so thanks for filing this! I do wonder if there's a way we could make use of the original query_string parameter but I admit that I haven't dug too much into the PR yet.

[codecov]

Codecov Report

Merging #2268 (8d5dbe7) into master (68da009) will increase coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head 8d5dbe7 differs from pull request most recent head cacb3f3. Consider uploading reports for the commit cacb3f3 to get more accurate results

@@            Coverage Diff             @@
##           master    #2268      +/-   ##
==========================================
+ Coverage   87.61%   87.63%   +0.01%     
==========================================
  Files         145      145              
  Lines        8851     8865      +14     
==========================================
+ Hits         7755     7769      +14     
  Misses       1096     1096              

Impacted Files	Coverage Δ
CTFd/utils/initialization/__init__.py	92.27% <ø> (ø)
CTFd/api/v1/scoreboard.py	95.38% <100.00%> (ø)
CTFd/cache/__init__.py	91.75% <100.00%> (+0.74%)	⬆️
CTFd/views.py	82.43% <100.00%> (+0.38%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[GramThanos]

Let me describe some things:

Regarding the query_string, the problem is that when you define it will change the flow of the https://github.com/pallets-eco/flask-caching/blob/ed4c2556f42a610854ab4bcc784dca5534000f38/src/flask_caching/__init__.py#L477 function, and thus the custom function for generating the cache key will not be called.

This is the reason why I decided to script a new make_cache_key function instead. Furthermore, since the query_string takes into consideration all the parameters given, using only the parameters that the backend uses it is better.

But my changes also introduce a new problem. Now the cache key includes a user defined input thus it should be used with caution and it is not always predictable. Examples:

URL	Old cache key	New cache key
/api/v1/scoreboard/top/1	view/api.scoreboard_scoreboard_detail	view/api.scoreboard_scoreboard_detail_count_1
/api/v1/scoreboard/top/10	view/api.scoreboard_scoreboard_detail	view/api.scoreboard_scoreboard_detail_count_10
/api/v1/scoreboard/top/100	view/api.scoreboard_scoreboard_detail	view/api.scoreboard_scoreboard_detail_count_100

In this particular case, the user input is always int thus I don't see any way that it could result in a problem. Though, right now there isn't a way to clear all these caches in a wildcard way, thus, I set the code to clean only the view/api.scoreboard_scoreboard_detail_count_10 that is the default used by the app front-end. External apps using other counter will have to wait the other cache keys to expire.