Fix LimboAPI login injection on Velocity-CTD

[gbpii]

Velocity-CTD does not expose ConnectedPlayer.DEFAULT_PERMISSIONS (it uses DEFAULT_PERMISSION_RESOLVER instead), which caused LoginTasksQueue static initialization to fail with NoSuchFieldException during player connect.

Update LoginTasksQueue to prefer DEFAULT_PERMISSIONS when present (standard Velocity), and when absent,
reflect DEFAULT_PERMISSION_RESOLVER and wrap it into a PermissionProvider so PermissionsSetupEvent can still run.

This restores LimboAPI login injection compatibility with Velocity-CTD.

Fixes: #232

[UserNugget]

Thanks!

[mdxd44]

Why on earth is the developer of this mess making changes like that in the first place?
This is just change for the sake of change, it breaks compatibility and makes absolutely no sense. It is not even being done for optimization reasons, but simply because they can.
I don't think LimboAPI and similar plugins should have to bend to these kinds of forks.

By the same logic, i could create my own fork, add a bunch of useless features that could be implemented via plugins anyway (even if with some hacky workarounds using reflection), rename classes just because i don't like their names, and also add a shit ton of pointless formatting and javadocs so that making a diff against upstream becomes impossible because the diff ends up being 50k lines long, and then blame the compatibility issues on the plugin developers.

[WouterGritter]

Why on earth is the developer of this mess making changes like that in the first place? This is just change for the sake of change, it breaks compatibility and makes absolutely no sense. It is not even being done for optimization reasons, but simply because they can. I don't think LimboAPI and similar plugins should have to bend to these kinds of forks.

By the same logic, i could create my own fork, add a bunch of useless features that could be implemented via plugins anyway (even if with some hacky workarounds using reflection), rename classes just because i don't like their names, and also add a shit ton of pointless formatting and javadocs so that making a diff against upstream becomes impossible because the diff ends up being 50k lines long, and then blame the compatibility issues on the plugin developers.

We had a permission check that took up to 86.400 Player#hasPermission checks (velocity.queue.timeout.X where X, in seconds, could be up to 1 day). This change was made to keep this legacy (admittedly bad) permission check to avoid breaking existing setups, and to improve its performance in cases where LuckPerms (and in the future other permission provider plugins) were used.

See: https://github.com/GemstoneGG/Velocity-CTD/blob/libdeflate/proxy/src/main/java/com/velocityctd/proxy/permission/PermissionUtils.java
See: https://github.com/GemstoneGG/Velocity-CTD/blob/libdeflate/proxy/src/main/java/com/velocityctd/proxy/queue/VelocityQueueManager.java#L469

Instead of assuming a feature like this was implemented in bad faith, please skim the source code in the future before making comments like that, which doesn't help anything.

With the same logic I can ask why reflection is being used to grab internal fields in LimboAPI. But I'm not going to, because I understand that sometimes you need an approach like this, especially in a heavily integrated plugin like this.

[WouterGritter]

Instead of shouting at each other, please open an issue on our side to re-introduce ConnectedPlayer#DEFAULT_PERMISSIONS and I'll take a look at it tomorrow.

We had also kept ConnectedPlayer#setPermissionFunction, a protected, internal, non-API method that was being called by plugins through reflection to maintain compatibility with other plugins. Adding back in ConnectedPlayer#DEFAULT_PERMISSIONS is not unreasonable if you're willing to make the request.