Make TimetableSnapshot state final

[vpaturet]

Summary

This PR refactors the TimetableSnapshot class to make its shared state final.
The intent is:

1. making clear that the TimetableSnapshot fields are immutable after publication.
2. preparing further refactoring steps where the snapshot could be published without using a lock.
   According to the Java Memory Model (https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5), final fields provide additional protection against re-ordering and can be used to implement thread-safe immutable objects without synchronization.

Note: the field TimetableSnapshot.dirty remains mutable, but is not used by reader threads.

Issue

No

Unit tests

No

Documentation

No

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.63%. Comparing base (8de9f88) to head (b508c79).
Report is 2 commits behind head on dev-2.x.

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #5968   +/-   ##
==========================================
  Coverage      69.63%   69.63%           
- Complexity     17129    17132    +3     
==========================================
  Files           1937     1937           
  Lines          73742    73744    +2     
  Branches        7546     7546           
==========================================
+ Hits           51351    51353    +2     
- Misses         19754    19755    +1     
+ Partials        2637     2636    -1     

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

[abyrd]

Looks good. Although making the fields final doesn't prevent changing the contents of the collections, it expresses the intent and moves in the right direction.

The that setting all the final fields in the constructor provides additional reordering/atomicity guarantees is important. If it's not mentioned in the javadoc here, it should be mentioned at points where the object references are handed off between threads. If only to ensure someone doesn't inadvertently lose this characteristic in the future.

[abyrd]

@vpaturet didn't you say earlier that this field was the only one that was not final? Looks like it is indeed final, so this class is essentially a record. Not that I'm advocating changing it to one, just pointing out this detail.

[vpaturet]

I was referring to this field:
private boolean dirty
which needs to be updated during the lifecycle of the buffer snapshot, but is not used in the published snapshot.

[abyrd]

Sorry, I meant to put the comment on private final boolean readOnly; but your comment still applies: the non-final field is the one right below it (dirty) which I for some reason didn't notice.

[vpaturet]

Looks good. Although making the fields final doesn't prevent changing the contents of the collections, it expresses the intent and moves in the right direction.

The that setting all the final fields in the constructor provides additional reordering/atomicity guarantees is important. If it's not mentioned in the javadoc here, it should be mentioned at points where the object references are handed off between threads. If only to ensure someone doesn't inadvertently lose this characteristic in the future.

I will merge this PR as is and add Javadoc about safe publication of final fields in a follow-up PR.