Check that the events and rounds in the submitted results json match the events page

[jfly]

Currently, it's possible for a delegate to submit results for a competition that do not match the information they put in the events page. Ways in which things could differ:

• The scheduled number of rounds of an event does not match the number of rounds that actually happened.
• Scheduled events may not have actually happened. Note that this is slightly different than the above item about "scheduled number of rounds" matching the "number of rounds that actually happened". On the WCA website, it is possible to add an event without any rounds, but we would want to complain if the results came in with 0 rounds for that event.
• The number of solves in the round changed (perhaps it was scheduled as 333mbf best of 3, but actually only was best of 1).
• The combined nature of the round changed (perhaps it was scheduled as a not combined round, but the round actually did end up being a combined round with a cutoff).
• The results contain results that violate the planned time limits.
• The results for combined rounds have results that violate the cutoff.

Additional checks in "persons":

• Check and warn for January's 1st DOB
• Check for identical names without WCA ID

We should check for these discrepancies at the time a delegate attempts to submit results. This will save the results team from detecting these issues and wasting time communicating with the delegate about these mistakes.

[pedrosino]

There's also the possibility that not all events have results - some event was not held at the competition.

[viroulep]

Gathering some notes to myself, mostly to not forget them and eventually get feedback if I'm stating something dumb:

• the JSON should definitely be validated by a JSON schema, currently it's a very long test in the php code.
• individual results validation (eg: best is best, average is correctly computed, ...) should be moved to a concern, and be applicable to both Results and InboxResults.

[viroulep]

Interestingly, the validation currently written here is wrong.
Or rather the way we do compute_correct_average is wrong, as we're using the division on integers instead of floats + rounding.

I found this out while working on checking the results: according to our validation method the result with id 2222070 is not valid, but it's actually correct!
Values are:

4376, 4518, 5038, 5485, 6477

Average is 5013.66, average in the db: 5014, average expected by the validation: 5013.
IIRC we do round these numbers, so the average in the db is right, and the validation is wrong.

@SAuroux could you please confirm that in such cases the expected average is 5014?

So I'm pretty sure we never run these validations otherwise we would have found this out a long time ago :p

[SAuroux]

Hm, what kind of check is this and were should it be executed in theory?

Of course, the average should be 5014 in accordance with https://www.worldcubeassociation.org/regulations/#9f1

[viroulep]

It was introduced in #978, I believe this was one of the steps needed towards #977.
So at some point it will be used (I plan to use it actually), but for now I think it's intentionally unused.

[jfly]

Good catch, @viroulep! I've fixed the rounding bug in #3100.