Add support for Standalone Geyser (without Floodgate)

[Smart123s]

Summary of your change

I wanted to add support for servers with Geyser, but without Floodgate. Previously, they were all treated as Java players. Now they are not, and this gives us the ability to further configure Offline Geyser and Java name conflicts.

Notable changes in FastLogin's functionality:

• 00196d8, 8d641a1: Created a superclass called BedrockService, so FloodgateService and GeyserService can share some code.
• 3549465#diff-69f42c2b3e5137fc6ca05432413cc958fbf5fc288bf7ec872ce83e5374cfc507: Added the ability to resume Java checks for Geyser players
• 06ef96f: Added the ability to allow Geyser players with conflicting Java names to join the server, even if it would be prohibited by other configuration options in FastLogin (such as nameChangeCheck)

Minor changes (could have been in a separate PR, but I'm lazy):

• 9c0c4cb and dd2dbdb

For more details, read the individual commit messages.

Related issue

Comments by @jondycz at

• Fix Floodgate player detection (caused by prefixes) #635 (comment) -- and comments after this
• Error cannot reply to EncryptionRequestPacket on Floodgate players #616 (comment) -- and comments after this

Additional stuff

In config.yml, allowFloodgateNameConflict should now be called allowBedrockNameConflict, however changing that would break existing configurations. It would be ideal, to create a config migrator for this. Or any other ideas?

[Smart123s]

https://github.com/games647/FastLogin/runs/3989837231?check_suite_focus=true

Ummm, it built fine on my computer... and I have even cleared the Geyser repo from my cache.

EDIT: OK, it's because Ubuntu 20.04 (CI) server builds with Java 11, while I use Java 17 on my PC. I'll try to run my Java 17 build on a Java 11 server. If it doesn't work, I'll downgrade Geyser in pom.xml.

[Smart123s]

So the latest version of geyser that supports Java 8+ is build#849. Afterwards, they require Java 16+ (GeyserMC/Geyser@bc0cfde). However, it is impossible to join a server that runs Geyser build#849, because it requires an outdated version of Minecraft: Bedrock Edition. And as we all know, we don't have a version selector for BE. So backwards compatibility with legacy versions of Geyser is useless.

Joining a server that runs Geyser build#849 and Java 11

I have built FastLogin 06ef96f with Java 17, then installed it on a server with Java 11 (without Geyser ofc.), and it worked without any problems.

So I think that the reliable long-term solution here would be to build FastLogin with a Java 17 JDK, but still target Java 8. Is it possible to do this on the CI servers?

As a short-term solution, I've force-pushed a commit that downgrades Geyser to 1.4.2 which still supports building with Java 8. The API didn't change (or I didn't notice it*), so FastLogin will work with servers that run the latest version of Geyser, even if we target an older version (at least for now...).

*Fun fact: by accident, I've actually targeted Geyser 1.2.1 at ceb5ed2#diff-2292c53027067d5c27e9aa916705526918e334a0f84e379313e60e48f78f4a4e (I've overwritten that via a force-push), and everything still worked with that. Although there's not much Bukkit specific code, so there aren't many things that could have gone wrong. And core was targeting 1.4.3

[TuxCoding]

The target JDK is enforced by Maven settings. However that the CI ensures is that the developer can still use an older version of the JDK.

In my opinion it's fine to bump it. For developers it's easier to update than for servers. Java 17 is LTS, but since Mojang specifically uses Java 16 we should use that.

[Smart123s]

I've reverted 2791682, and updated Github Actions to use Java 17. Does this also apply to the CodeMC CI server?
I'll look into the CodeQL error later today.

[TuxCoding]

Thanks for the heads up. CodeMC will now use Java 16 for FastLogin.

[Smart123s]

Ok, GitHub Actions is now building. I've gone with Java 16 to have the same results as with CodeMC, which is used to release new versions.

[jondycz]

Summary of your change

I wanted to add support for servers with Geyser, but without Floodgate. Previously, they were all treated as Java players. Now they are not, and this gives us the ability to further configure Offline Geyser and Java name conflicts.

Notable changes in FastLogin's functionality:

• 00196d8, 8d641a1: Created a superclass called BedrockService, so FloodgateService and GeyserService can share some code.
• 3549465#diff-69f42c2b3e5137fc6ca05432413cc958fbf5fc288bf7ec872ce83e5374cfc507: Added the ability to resume Java checks for Geyser players
• 06ef96f: Added the ability to allow Geyser players with conflicting Java names to join the server, even if it would be prohibited by other configuration options in FastLogin (such as nameChangeCheck)

Minor changes (could have been in a separate PR, but I'm lazy):

• 9c0c4cb and dd2dbdb

For more details, read the individual commit messages.

Related issue

Comments by @jondycz at

• Fix Floodgate player detection (caused by prefixes) #635 (comment) -- and comments after this
• Error cannot reply to EncryptionRequestPacket on Floodgate players #616 (comment) -- and comments after this

Additional stuff

In config.yml, allowFloodgateNameConflict should now be called allowBedrockNameConflict, however changing that would break existing configurations. It would be ideal, to create a config migrator for this. Or any other ideas?

Idea: Make allowFloodgateNameConflict an alias for allowBedrockNameConflict

[Smart123s]

In the latest force-push, I have replaced this line:

https://github.com/games647/FastLogin/blob/a2ab79cd4112c314f28f16359c63d60c0c79ee1d/core/src/main/java/com/github/games647/fastlogin/core/hooks/bedrock/GeyserService.java#L69

with this:

        for (GeyserSession gSess : geyser.getSessionManager().getSessions().values()) {

because the first one is no longer present in Geyser.

If something goes wrong, this might be the cause.

[TuxCoding]

Merged manually