Report Viewer Bug Fixes and Tests for v4.0.0 Release

[sebinside]

There are a couple of bugs and tests left to make the report viewer release ready for version 4.0. This issue collects the known problems:

1. Matches are not represented correctly if not all source code files are in the root folder (which is, e.g., the case with packages in java). In the report viewer, files are represented by their name while matches are represented with the full path. This breaks the viewer. This issue is also documented in Enhance the new Report Viewer #357 and Report Viewer does not show matches properly #658. Here, we need to use the relative path whenever possible to avoid any collisions in file names (see also problem 2).
2. The Report Generation does overwrite source code files if they have the same name because all files are "flat mapped", i.e., written in one single folder per submission. It does not throw an error but will put out wrong results that might be noticed later (or even not noticed at all). Here, the solution is probably to preserve the original folder structure also in the resulting zip file in the submissions folder. This can be easily replicated by creating a structure with files with different content in a submission like this:

   SourceFile.java
   subfolder/SourceFile.java
   

3. Problem 2 could also affect the multi-root and subdir features (see the readme for details on the usage). In particular, this might break if two root directories have the same name. Here, more testing is required.
4. The report viewer sometimes breaks with clusters activated. This problem requires more insights to be replicated. Also, Problems 1- 3 are more important. For now, cluster serialization is disabled in Quick fix for matches not display properly in the report viewer. #691.
5. Add a hard version flag to the overview.json that relates to the release version, e.g., v4.0.0. If the flag does not fit the report viewer version, a warning should be printed. This is already addressed in a naive way in Quick fix for matches not display properly in the report viewer. #691.

[JanWittler]

This problem even extends further. We implicitly expect the language frontends to provide tokens with file names relative to the root directory of the associated submission, as we write that file name of the token to the JSON output. Thus, if the assumption is not hold, the file cannot be found, even if we fix things in the report viewer.
I refactored Token::file to type File in #688 such that the submission-relative file has to be computed explicitly by the report generator instead of having this implicitly distributed over the language frontends.

[sebinside]

This issue has been replaced by #710.