Follow tombstone and predecessor history

[MadLittleMods]

Follow tombstone and predecessor history

Fix #59

Other updates:

• Update tests to use /roomid/room1/date/2022/01/03 format instead of trying to retrofit the weird alias stuff on there. Which also makes the fancy to actual URL utilities much more simple.
• Update to specify archiveMessageLimit in the test case because pages have different number of events depending on if we are against a boundary, hidden events, etc.

Dev notes

• Follow tombstone and predecessor history when visiting room on a given day
• Follow tombstone and predecessor history for /jump
• Write tests
• Edge case: Someone can create a circular reference which will cause us to keep redirecting the user around in a loop. Do we care?
  • Maybe not as the ERR_TOO_MANY_REDIRECTS in the browser will handle it
• Does it work in a Gitter-like historical room where we created the room with some date X and imported history with timestamps before X?
  • Do we need some causality query parameter for /timestamp_to_event? Like /timestamp_to_event?dir=f&ts=123&event_id=$123 meaning find the closest event from ts looking forward after event_id (the causality part, "A after B")
    • Perhaps we could just see some causality by observing m.room.create popping up in /timestamp_to_event?dir=f when we /jump. If we see m.room.create, then assume we've reached the end of the room and move to the successor
    • Someone could also tie us in knots by making timestamps circular so we probably do need a causality param for /timestamp_to_event
    • Created MSC3999 to track adding a causal query parameter to /timestamp_to_event?event_id=$abc

[MadLittleMods]

I feel like I can't justify this 🤔 but it does seem correct from tested behavior.

I think my reasoning for using currentRangeEndTs before was that we could keep paginating with day precision if we were showing more than a day for each page. But then this falls apart when you have a bunch of messages from the same hour that fill up multiple pages. As a note with this change from currentRangeEndTs -> currentRangeStartTs, we did have to update the can jump backward to the previous activity test to use hour precision now.

Using ts or currentRangeStartTs makes sense for the reference point of being the jump point as in "The closest event is from the same hour we tried to jump from."

Using ts makes various tests fail with various precision differences. Probably because of the - 1/+ 1 stuff that we want to remove in the future anyway when MSC3999 lands.

But those don't seem like explanations for why (the truth kernel)

[MadLittleMods]

I've left a link to this discussion thread so people can get some context. But I think I will opt to merging this PR without figuring this out. Will just have to contemplate this more and fill it out when an epiphany happens.