Update to ical4j 4.x #112

Why

We need up-to-date libraries that we build upon. For instance ical4j 4.x has bug fixes that we need and up-to-date timezones (outdated timezones create more and more problems, see #113).

What

Updating ical4j 3.x to 4.x is a huge change because a lot of calls change, also semantically.

Main change is that it now uses the Java 8 Time API (also for timezones). See the mapping.

See also:

• https://ical4j.github.io/2024/06/19/ical4j-v4-released.html
• https://ical4j.github.io/2024/02/24/ical4j-v4-changes.html

How not to break everything

According to the "always have a working main branch" principle: All sub-issues should be merged to the ical4j-3to4 branch because they will break compilation and tests. So we can work on that one until it's finished and working, and then merge that one into main (with rebase/merge, not squash).

However PRs must ensure that the tests of their domain succeed again. For instance, if a PR rewrites CalendarUidSplitter, then it must make sure that the tests regarding this class succeed after the PR.

When creating PRs, the "Create a branch" link in the Github issue could be useful. You can select the ical4j-3to4 branch as base branch there:

(For next time: Can we just create a ical4j-3to4/xxx branch manually? I like the slash to group everything around ical4j-3to4. However Github said it's not a valid branch name.).

Further hints

(We can add things here when we discuss how to proceed.)

• Update helpers "on the go"? Will probably cause merge conflicts, which could be a chance to extract the best of both variants
• Set up branch protection rules for this sprint?
• Refactoring during PRs: yes / no / minor?
• If it turns out that we forgot something (for instance a class/package) in the sub-issues, how/when to add it to the sprint?
• It could be useful to the split sub-issues again, for instance [ical4j 4.x] Update ICalendarGenerator/ICalendarParser #185 into one sub-issue/PR for the generator (+ tests) plus one sub-issue/PR for the parser (+ tests).