Add profile cache

[Jikoo]

Trades a relatively small amount of disk space (about 50 bytes per player) and additional async processing post-login (which is generally a hot area for plugins already) in exchange for not relying on the server's user cache or having to load every single player from disk to check their name.

There is one behavioral change here - for the SQLite implementation, I opted to require the first character to match (case-insensitive) as it provides a massive speedup to the already-much-faster query.

TODO:

• Expose PlayerLoader's ProfileStore getter and setter to allow third party implementation (and make sure to log w/ class when used!)
  • I've elected to not make this official API for now because I'm still on the fence about it. I will likely not resolve this until I also expose allowing custom player loader implementations.
• Consider refactoring JdbcProfileStore
  • Removed; it would have to be rewritten to handle connection pooling anyway.
• Consider refactoring importer to allow importing from arbitrary other implementations
  • Requires a getAllProfiles method
  • Given that this is not going to be official API yet, I don't want to bother for now. There will likely need to be events created for starting and finishing imports and things of that nature.
• Consider adding a method to get profile by UUID
  • Just get the player directly
• Consider adding profile expiration
  • last_update exists for this
  • For now I don't want to bother with expiration. I don't see it as a particularly desirable thing to force lookup via UUID for profiles over a certain age. People who are interested can manually run a delete query using the provided field.
• Consider WAL
  • WAL offers a not-insignificant performance improvement. During normal operations, we only ever write with the one connection. Needs extra handling during shutdown.
  • After some consideration, I don't want to use WAL. While the database location currently is not configurable, I could see several server instances behind BungeeCord et al using the same database. Using WAL would cause a lot of extra headache there. Users who do want to enable WAL are free to do so manually.

It may be a good idea to optimize the JaroWinkler implementation in a future PR - that's likely the largest bottleneck now.

[Jikoo]

I've tested this and it appears to be working correctly. There are a couple of things I'm not super thrilled with at the moment.

• When importing, the final batch is not completed before the importer reports itself done. It is enqueued, but there is no guarantee that it will actually complete successfully. I imagine in that case writing completion state would also fail, so I'm not sure I want to bother changing it. Completion is another case I had missed being a race condition for WAL as well, so I feel better about having opted not to go for it.
• When performing a batch, any new entries added between the start of the batch actually being prepared and the batch being completed are stuck enqueued until another element is added or the server shuts down. This is unlikely to be an issue aside from very specific situations like trying to open a first-time player who logged in and out right at the end of data importing. I will likely change this to attempt to re-queue anyway, assuming that the server is shutting down and the sync save will kick in if scheduling fails.

/e: Actually this is a pretty large problem because it means that the import process might leave a lot of stuff hanging depending on timing. In general, importing should probably bypass the normal batch gather and potentially do its own batching. I had wanted to create a more general solution, but getting slightly more specific seems smarter.

[Jikoo]

@R00tB33rMan I'd appreciate your input if you have the time.

I think this is about ready on my end. I do only have access to about 4k user files, but everything seemed pretty smooth. The import took 62s, largely due to the I/O speed of the HDD I store my test server on. After that, lookup performance was really solid, fractions of a second.

[R00tB33rMan]

Hey, @Jikoo! I had a good look at this, and as far as I'm concerned, nothing pops out to me from reviewing the last 6 minutes or so and compiling locally. (And of course, no errors)! I'd argue that this is probably a good start, and once you refine any other to-dos, it should be good to go!