Support importing problems with problem_format_version: 2023-07-draft

[mpsijm]

Description of the enhancement request

For BAPCtools, we're starting to implement the new version of the problem package format specification (https://icpc.io/problem-package-format/spec/2023-07-draft.html), see RagnarGrootKoerkamp/BAPCtools#425 and related PRs.

However, we realized that DOMjudge will not yet be able to import problems that adhere to the new version of the spec. For instance, in problem.yaml we need to revert type: back to validation:, and the time limit cannot be imported from limits.time_limit but has to be in a .timelimit file: RagnarGrootKoerkamp/BAPCtools@417d27a

Additionally, we still want to implement the new output validator and visualizers, which are no longer a collection of multiple, but only one singular program: RagnarGrootKoerkamp/BAPCtools#424.

It would be great if DOMjudge can import problems with problem_format_version: 2023-07-draft without problems. Most likely, most of the adapting can happen in https://github.com/DOMjudge/domjudge/blob/main/webapp/src/Service/ImportProblemService.php. Some things may require some reordering: for example, parsing the time limit from problem.yaml requires the YAML to be parsed already, but currently, the time limit is already read from domjudge-problem.ini and .timelimit before setting some default values and then parsing the YAML. I can probably help out with adapting the problem import code, but then I'd like some architectural hints for the ordering of parsing things. 😄

One feature that I don't think DOMjudge can support fully yet with just tinkering with the import code, is the testdata.yaml files in data/ that replaces the validator_flags: key in problem.yaml, but allows overriding the input/output validator arguments for subdirectories of data. This probably warrants an entire separate issue / discussion. 😂

Note that, even when DOMjudge 8.4 (or some later release) would support the latest problem package format spec, we'll have to keep the backwards-compatible export in BAPCtools for at least a couple more years, because not all contests will run the latest version of DOMjudge. But still, if we never start supporting the new spec in DOMjudge, we'll have to wait even longer before we can abandon the legacy format. 😛

[meisterT]

re time limit: I wrote this once in a slack channel:

This is somewhat hilarious:
DOMjudge reads problem timelimits from problemset.yaml, <problem>/.timelimit, and <problem>/domjudge-problem.ini, while PC2 reads the time limits from <problem>/problem.yaml (limits -> timeout).

Now it seems we have a new location limits -> time_limit - I hope that's here to stay? When is the spec moving out of draft status? cc @nickygerritsen @eldering

[meisterT]

Re: multiple output validators: we are already relying on the fact that there is a single output validator: https://github.com/DOMjudge/domjudge/blob/main/webapp/src/Service/ImportProblemService.php#L953
(although in a different directory)

[eldering]

re time limit: I wrote this once in a slack channel:

This is somewhat hilarious:
DOMjudge reads problem timelimits from problemset.yaml, <problem>/.timelimit, and <problem>/domjudge-problem.ini, while PC2 reads the time limits from <problem>/problem.yaml (limits -> timeout).

Now it seems we have a new location limits -> time_limit - I hope that's here to stay? When is the spec moving out of draft status? cc @nickygerritsen @eldering

It should have been released already, but for lack of effort to push wrapping up the last tiny details... Let me see if I can push this a bit.