Allow rulesets to specify a SimpleUpdateManager so they could announce updates

[LumpBloom7]

Depends on #24484

The updating process is handled via RulesetUpdater which loads all of the updaters specified by non-legacy rulesets (if they do specify any)

Ideally the rulesets should create their own implementation of a SimpleUpdateManager, however atm there is nothing stopping rulesets from incorrectly using SimpleGameUpdateManager (they should possibly be internal instead).

There is currently no mechanism to check if the ruleset itself is targeting a later version of lazer.

An example of a ruleset side implementation of the UpdateManager: https://github.com/LumpBloom7/sentakki/blob/UpdateManager-test/osu.Game.Rulesets.Sentakki/SentakkiUpdateManager.cs

[EVAST9919]

The idea is nice but the more rulesets implementing this you have - the faster you will be rate-limited by the github. I encountered this issue while trying to implement somewhat similar functionality for my Sandbox ruleset.
At the end decided to make a button to manually check each ruleset individually.

[LumpBloom7]

Good point about rate limit consideration. I haven't looked into the rate limits, but I didn't think it was that low (assuming a reasonable number of rulesets)

I can't exactly find any numbers in relation to rest api limit, but I may have been looking in the wrong place.

[EVAST9919]

Something something 50 per hour per user
It's stated in a bit complicated manner but I've rate-limited myself back then within ~4 consecutive game sessions and 13 rulesets so looks like math adds up.

[LumpBloom7]

I don't think it would be a significant problem for most users in a practical sense. (though I do acknowledge a little bit of margin is nice)

We could cut out a fair bit of calls by using a "last-check time" comparison.

On debug/non-deploy builds of lazer, it doesn't check for updates, so devs in theory shouldnt hit the limit either.

In the event that the limit is reached, it'll resolve itself within an hour, and the user wouldn't even notice(unless they are expecting updates on n start of lazer)

[EVAST9919]

Yeah, I'm not saying the idea is bad, just something to be aware of.

[bdach]

Ideally the rulesets should create their own implementation of a SimpleUpdateManager, however atm there is nothing stopping rulesets from incorrectly using SimpleGameUpdateManager (they should possibly be internal instead).

Why does the example implementation of a ruleset updater provided in the OP "incorrectly" inherit from SimpleGameUpdateManager, then?

[LumpBloom7]

Oof that is a mistake from being not reading intellisense properly

[andy840119]

Nice idea!

But i'm wondering:

1. I guess osu might provider the marketplace for ruleset creator to upload their ruleset eventually(?)
2. What if the case ruleset is not in the github (e.g. Gitlab) or private repo?
3. How to handle the localization file? Or if the ruleset container more than one dlls? (A little bit out of topic but i prefer all ruleset-related dll files and resource should be zipped into single file with special extension name like sentakki.ruleset)

[LumpBloom7]

1. I believe so, this is more of a stop gap solution until then.

2. The changes suggested by bdach over on the other PR should make this more feasible, as one can define a non GitHub update checker relatively easily. If it is on a private host, then a sort of dummy repository could be used to check for updates, while pointing to a link to Patreon or something (similar to https://github.com/EVAST9919/yoso-version-tracker)

3. At the moment the aim is to open a link provided by implementations, which could point more generally to the main release page rather than directly to a specific dll file, so it shouldn't be a problem. The bundling is a neat idea though.