Issue/#724 generalize rating initialization

[Askaholic]

Implement reading the initializer from the database.

One question is whether the global and ladder_1v1 ratings need to continue to be eagerly created. Right now even completely new players will have a global and ladder rating in their ratings dictionary, however is this really necessary?

Closes #724

[Askaholic]

I'm going to change how I'm handling dependency cycles. Instead of disallowing cycles, I'm going to rewrite the code so it only ever looks back 1 step, instead of trying to look back recursively. That way if e.g. global is initialized based on 2v2, and 2v2 based on global, then essentially whichever one gets played first will be used as an initializer for the other.

Also need to do this in the rating service as well, since unfortunately this code is duplicated.

[Askaholic]

I decided that the desired behavior is actually to initialize ratings recursively, and use the default rating when a cycle is detected. This would both allow dependency chains like:

• 2v2 -> global -> ladder1v1. If neither 2v2 nor global exist, but ladder does exist then both global and 2v2 will be initialized based on ladder. The only tricky thing here is if the deviation for ladder is really small we don't actually want to increase it twice.
  and cycles like:
• 2v2 -> global -> 2v2. If one of them exists, the other will be based on the existing one, and if neither exist then a default will be used for whichever one is requested first.

Given one of the recent client bugs we saw with trying to display map pools when no rating existed, I think it is actually still a good idea to eagerly initialize ratings. However, this can cause a weird scenario where for example the following happens:

1. Player who has never played 2v2 logs in, and their 2v2 rating is initialized to their global mean
2. Player plays a whole bunch of global games changing their mean significantly (maybe they're kinda new and dev is high so mean changes fast)
3. Player then queues 2v2, but the current 2v2 rating used by the matchmaker is still based on their old global rating when they logged in
4. Game finishes, their 2v2 rating is re-initialized based on the new global rating and persisted to the database, from now on rating should be as expected.

In this case the first 2v2 game will be balanced based on outdated info. So I think it would be ideal for the PlayerRatings dict to keep track of which ratings were set externally (meaning they are more or less tied to the database in some way) and which ratings were automatically set as part of the initialization process. These automatically set ratings should then be re-computed whenever they're queried to ensure they are up to date. They do need to be set on the object so that they can be iterated over, in which case they don't need to be recomputed.

[codecov]

Codecov Report

Merging #740 (7ae75a8) into develop (716717f) will decrease coverage by 0.05%.
The diff coverage is 94.11%.

Impacted Files	Coverage Δ
server/__init__.py	91.13% <ø> (ø)
server/db/models.py	100.00% <ø> (ø)
server/matchmaker/matchmaker_queue.py	91.85% <66.66%> (-0.58%)	⬇️
server/rating.py	93.58% <92.06%> (-6.42%)	⬇️
server/lobbyconnection.py	94.24% <100.00%> (+0.01%)	⬆️
server/players.py	100.00% <100.00%> (ø)
server/rating_service/rating_service.py	96.44% <100.00%> (+0.72%)	⬆️

[Askaholic]

I think I've implemented everything that I mentioned above.

• Recursive initialization with cycle detection
• Recomputing auto initialized ratings whenever they are queried

I also eliminated the duplication by making the rating service use PlayerRatings objects for computing initialization. It now loads all of a players ratings from the database and throws them into a PlayerRatings object, then it queries the object for the particular rating that its interested in.

[BlackYps]

I thought about how we want the dependency chains to be in practice.
I think ideally we would want global <--> 4v4 <--> 2v2 <--> 1v1. However this requires two references and a way to determine which preference should be preferred, if both exist.
With one reference we can build the chain 1v1 -> 2v2 -> 4v4 -> global -> 2v2. I think this one will work good enough, so we can save the trouble of implementing the double reference version.