Apparently, the context["m.relates_to"] = {"m.in_reply_to": {event_id: event.event_id}} has always been there... The more you know!
I forgot I didn't, apparently, add it myself.
Also, while fixing the regression, I may as well introduce the note to EM, too.
2 caveats remain (and neither has anything to do with not passing ...channel):
* ugly-error with permissions (fixed)
* no auto-reset (maybe fixed??? - it's either because I DID pass channel (ironic) or because of no await, testing option 1 now)
Also, improved comment consistency
🎵Give up free will forever - their voices won't be heard at all!🎶🎶Display obedience...🎵
Where was I, again? Ah, right. I'm supposed to make the judgment call (I am the unenlightened masses) ((Someone tries to link their, fkin, smart-bidet smart-home-controller-room to a Stage or something and imma be cooked))
I was stripping the ping before because I thought it just pings the thread-author (which I found kinda pointless). But I didn't actually remove the code that figures out who to ping (because I happened to reuse the „if” around it, and didn't remove the setting itself because I didn't pay enough attention to it and just assumed it has some side-effects). I just tried to remove it finally (because my thought was „Wait, WHY are we setting m.mentions only to remove it?”), only to realize that the code does something entirely different (it pings the one under whose message a thread is about to be created, which makes a lot of sense tbh), and actually shouldn't be removed at all and - on the contrary - I should stop removing m.mentions (and also fix Ellie-Mode so that it won't prevent m.mentions from being set even if it's enabled).
* use "" instead of „” to comply with English Language Standards Recommendations On Quotation Marks [TM], as per Cadence's request
* reflect current bot behavior (ie. it no longer bridges-as-replies, but mercilessly rips the message away from your caring arms)
* add Ellie-Mode
Notably:
* Don't do the unmarshalling and switch-cases, as Cadence asked
* Revert command handler returns to how they were before, now that we're not using the returned-command-name anymore.
Both sides of creation (M2D and D2M) use ensureRoom() instead of syncRoom() because it's impossible to know which one will fire first, and we wouldn't want a double-sync. At the same time, calling ensureRoom() as a way to CREATE a thread-room is perfectly safe because „Naturally, the newly created room is already up to date, so we can always skip syncing here.” and also thread-rooms aren't subject to manual-mode restrictions, so we can skip all „Does a channel_room entry exists or guild autocreate = 1?” checks (actually, the comment probably should reflect that - so I updated the comments, too.
Also, bridgeThread() is a separate function to make guard clauses possible instead of nesting 3 more layers of IFs like we were fkin YandereDev.
