Enforce immutability of published timetable snapshot

[vpaturet]

Summary

This PR makes use of immutable data structures in the timetable snapshot.
This ensures that attempts to modify the data structures after the snapshot is committed will fail fast.

In addition the immutable maps created by Map.copyOf() and ImmutableSetMultimap.copyOf() cannot contain null keys or values, providing a way to fail fast if these conditions are not fulfilled.

To further prevent attempts to modify a published timetable snapshot, methods that modify the states are either made private or are guarded by a condition on the readOnly field.

Note: It does not seem that in today's code any of these requirements on immutability is broken: the write API is not called after the timetable snapshot is created, null keys and values are not used, the collections are not modified after publication (but the objects they refer to may be modified).
The main purpose of this PR is to make these requirements more visible, to make sure they are not broken in the future, and to make reasoning on the timetable snapshot easier.

Issue

No

Unit tests

Added unit tests to check immutability (some existing tests already partially test the public API for immutability. The new tests are more focused on testing only this aspect)

Documentation

No

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.47%. Comparing base (15b49f9) to head (22ed45e).
Report is 24 commits behind head on dev-2.x.

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #5934   +/-   ##
==========================================
  Coverage      69.47%   69.47%           
- Complexity     17075    17079    +4     
==========================================
  Files           1936     1937    +1     
  Lines          73669    73679   +10     
  Branches        7539     7539           
==========================================
+ Hits           51180    51188    +8     
- Misses         19865    19870    +5     
+ Partials        2624     2621    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[leonardehrenfried]

Thanks for the explanation in today's meeting. This looks like a good change.

[leonardehrenfried]

I wonder if it would make sense to convert this to a SortedSetMultimap.

[vpaturet]

That would make the intent more obvious, but at the same time that would hide the SortedSet as an implementation detail of the MultiMap. But we need to keep control over this SortedSet to be able to implement copy-and-write (and to replace it by an ImmutableSortedSet) as done in #5941

[abyrd]

This looks like a great step in the right direction for the realtime updating subsystem! Thanks for explaining all your findings to us in the meetings.

For future reference: core changes here include replacing HashMap.clone() with Map.copyOf and using ImmutableSetMultimap.copyOf() when committing the read-only snapshot.