League Points Calculation + Task Scheduling

[GODrums]

Motivation

Solves tasks 3.2 and 3.3 of #170.

Description

Please checkout the textual description of how leagues are meant work in #170 first.

Summary league details (from #170):

• according to a player's current league points, they are assigned to exactly one of these leagues: bronze, silver, gold, platinum, diamond
• the starting rating should be 1000 and every leaderboard cycle increases/decreases a player's rating according to their performance
• rating changes are calculated according to the following formula:
  
  • s: leaderboard score, r: leaderboard ranking, p: player's league points
  • Description: The change in rating is equivalent to a weighted sum of the player's leaderboard score plus a placement bonus minus a point decay based on the player's current points.

This PR includes the fundamental logic for calculating leaderboard leagues:

• Adds a leaguePoints-attribute to the User, storing the user's current "league" as points.
• The LeaguePointsCalculationService calculates the ranking point change based on a user's result in the (completed) leaderboard. All details regarding the algorithm/formula are described in Leaderboard leagues #170.
• The LeaguePointsUpdateTask is a task scheduled at the end of every leaderboard cycle, which initiates the rating change calculation for the finished leaderboard

Testing Instructions

Next to standard reviews, I would also appreciate concept reviews regarding the used algorithm.

• Change the execution schedule in LeaderboardTaskScheduler such that the task executes instantly (e.g. scheduleWithFixedDelay and Duration.of(1))
• Run application-server and check calculated values in the console
• Evaluate yourself if applied rating changes seem reasonable

Checklist

General

• PR title is clear and descriptive
• PR description explains the purpose and changes
• Code follows project coding standards
• Self-review of the code has been done
• Changes have been tested locally
• Screenshots have been attached (if applicable)
• Documentation has been updated (if applicable)

Server (if applicable)

• Code is performant and follows best practices
• No security vulnerabilities introduced
• Proper error handling has been implemented
• Added tests for new functionality
• Changes have been tested in different environments (if applicable)

[FelixTJDietrich]

Other than the one comment this looks good. I thought about if it makes sense to not realize all the merged pull requests in memory, this could technically be done in the database.