Add new event TickRateChangedEvent

[Axionize]

This event fires when the tick rate is changed, either by a command or by a plugin.

Useful if you have code dependent on the tickRate (my use case is simulating and predicting possible player movements) and you don't want to have to poll the tickRate all the time.

[dawon]

Isn't the api/event itself missing?

[Axionize]

Thank you for noticing that. Not used to the paper build system. Let me fix that real quick.

EDIT: rebuildPatches ate my code I'm going to have to rewrite this...

[masmc05]

Also check https://github.com/PaperMC/Paper/blob/master/CONTRIBUTING.md#pr-policy, you're both missing comments on changed lines and you have imports instead of using fully qualified name

[masmc05]

Also, use https://jd.papermc.io/paper/1.21.1/org/bukkit/event/Event.html#callEvent(), not the plugin manager

[Axionize]

Pushed the actual event code

[Axionize]

@masmc05 I addressed all the changes you requested. Added comments starting where my patch modifies code, switched to using event.callEvent() and the patch now uses the FQDN instead of imports for changes in Paper-Server.

[Axionize]

I've addressed all issues that have been brought up. Is there anything else I need to do for this to be merged?

[Lulu13022002]

The event mix jetbrains and jspecify nullable annotations. And it's a bit iffy when a plugin change the tick rate cause the command executor doesn't receive the right tick rate in the feedback message (unlike the WorldGameRuleChangeEvent for example)

[Axionize]

I'll fix the notations but I don't understand your second concern, what exactly is the problem? That the message returned to the player won't reflect the new tick rate?

[electronicboy]

Paper events go in the paper package

[Axionize]

I was thinking about upstreaming this into Spigot later

[electronicboy]

if that's the case, then this PR is inherently blocked as it makes little sense for us to finalise the review and such of this into a state we're happy to merge it if we're going to potentially have to deal with breaking ABI changes from upstream

[lynxplay]

Which will inherently be the case as spigot does not expose the CommandSourceStack this event now provides.
Would be great if you can come to a decision whether or not you want to have this event in spigot-api soonish then. As cat mentioned, if this is going upstream, there is 0 point in this PR receiving reviews on paper and we can close it instead.

[lynxplay]

Any update on this? I'd really like to either merge or close this depending on your decision regarding moving this to upstream.

[Axionize]

I've decided to leave it in paper. Are there any other changes you'd like me to make?

[lynxplay]

Well as cat stated, the event should be in the paper event package

[electronicboy]

That the message returned to the player won't reflect the new tick rate?

Yes, the server prints the output of the tick rate, and yet, if a plugin mutates it, this value will be wrong; if we want to support mutation, the logic should be adjusted to get the new rate so that the message is displayed properly, rather than having invisible side-effects to end users

[Axionize]

I've restructured this PR so that mutations will be reflected in messages and return values.

[Axionize]

Hi, is there anything left for me to do before this can be merged?