This claims it requires a compatible homeserver, but that does not exist and hasn't for years. Let's just remove the option to stop giving people false hope.
Once notifications are decoupled from read receipts, this sort of thing should be more possible.
The `TimelinePanel` uses two timers to coordinate read marker and read receipt
updates. When the read receipt timer fires, we advance the receipt and send the
latest state of both your receipt and marker to the server. When the read marker
timer fires, we advance the marker visually, but do not send anything to the
server: we were relying on the slightly different schedule of the read receipt
to actually send the updated read marker. This means there's a time window where
it's possible to visually advance the read marker without ever sending it to the
server (if you change rooms before the receipt timer fires again).
To simplify the behaviour here and ensure we always commit the updated marker
when we move it, this change sends an update to the server at the same time as
moving the marker.
It's possible this may improve some of the behaviour reported in
https://github.com/vector-im/riot-web/issues/12338.
These TODO comments are expected to be fixed ASAP, but until that happens let's minimize the errors in the console for development.
For https://github.com/vector-im/riot-web/issues/12877
These all aren't using componentDidMount because they do something which causes application instability if componentDidMount were used. Much of these calls are expected to move into constructors once they are converted to real classes.
Somehow, live events can be missing a timeline, even though that should not
happen... This restores @uhoreg's previous version where we test for this case.
Fixes https://github.com/vector-im/riot-web/issues/12120
Stacktrace:
```
TimelinePanel.js?b9ae:1139 Uncaught (in promise) TypeError: Cannot read property 'getBoundingClientRect' of null
at Object._getLastDisplayedEventIndex (TimelinePanel.js?b9ae:1139)
at Object.updateReadMarker (TimelinePanel.js?b9ae:751)
at Object._callee$ (TimelinePanel.js?b9ae:613)
at tryCatch (runtime.js?4422:45)
at Generator.invoke [as _invoke] (runtime.js?4422:271)
at Generator.prototype.<computed> [as next] (runtime.js?4422:97)
at asyncGeneratorStep (asyncToGenerator.js?56ef:3)
at _next (asyncToGenerator.js?56ef:25)
```
This is needed because `require()` means something different in webpack - it ends up importing the module as something we didn't expect (and is occasionally async)
We use `export default` begrudgingly here. Ideally we'd use just `export`, though this entire SDK expects things to be exported as a default. Instead of breaking everything, we'll sacrifice our export pattern for a smaller diff - a later commit can always do the default export -> regular export conversion.
