Correctly represent the last week in rrules Part 2

[PeterNerlich]

Short description

#2992 Found and fixed a bug in rendering out recurring events to iCal format. However, our function to internally generate the next event instances using the recurrence rule was still broken.
This PR attempts to fix the implementation of that function and add tests to it which seemed to be entirely missing until now.

Proposed changes

• I decided to change how we store and handle the intention of "last occurrence in month" to using negative values to count from the end of the month instead of the start, rendering the functional changes of Correctly represent the last week in rrules #2992 unnecessary. But it should be closer to how iCal does it and be less ambiguous.
• As a consequence, specifying 5 to select the number of occurrence of the weekday in the month is still valid, but will now really only mean months with enough days to have a fifth e.g. Friday. Months too short will be skipped and not produce these events. This is however not selectable through the UI but something the system in theory supports but which we won't expose to users at this moment in time.
  • Add a data migration to change all existing RecurrenceRules with frequency monthly and week_for_monthly of 5 to a value of -1
• We now also support arbitrary counting from the end of month, so I took the liberty to also expose a value of -2 under the option of Second last week.
• I added tests for the iter_after() function. It seems like only to_ical_rrule() was being tested until now.

Side effects

• none come to mind

Resolved issues

Fixes: #3022, #2989

---

Pull Request Review Guidelines

[codeclimate]

Code Climate has analyzed commit c8caf43 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 75.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 83.4% (0.2% change).

View more on Code Climate.

[david-venhoff]

I think this will not fix our issue, because I think the actual bug is on the frontend, as I commented here: #3022 (comment)

@PeterNerlich Could you please try to verify this?

Still, this pr fixes another bug, so it would still be worth merging, just with a lower prio

[david-venhoff]

Assuming that this is not a critical fix anymore, our manual iter_after implementation seems error-prone and hard to maintain to me. Also it appears that dateutil library that we are already using has support for exactly the same functionality. So it seems like we could just replace this whole code with a simple self.to_ical_rrule().xafter() oneliner: https://dateutil.readthedocs.io/en/stable/rrule.html#dateutil.rrule.rrule.xafter
Could you try if that could work for our usecase?

[david-venhoff]

I think this would also close #2094