Using `QueueRemoteEvent` to blindly fire off the resyncing of spaces as
well as their child rooms effectively races, resulting in the child
rooms lacking a `network` in their `m.bridge` state.
To fix this, synchronously ensure that the spaces exist before bridging
their children.
This patch also makes it so that empty categories (categories that are
literally empty as well as categories exclusively consisting of channels
that can't be viewed by the user) are no longer bridged.
Further support cancellation (via concurrent Disconnect call) while
we're "sleeping" in connectRetrying. This is sorta half baked because we
don't handle cancellation post-Open, which should really be added so we
can avoid the sync.
Note that mute_only_on_create in the config seems to default to true.
When that is the case, the remote mute state only makes a difference
during initial portal creation.
* The split_portals config option is finally respected.
* This should prevent future room duplication when migrating from the
pre-bridgev2 version of the bridge, as we'll finally address guild
channels properly (that is, without a Receiver set, unless
split_portals is true).
* Fixes the totally broken UserInfo resolution in guilds.
* Adds support for USER_UPDATE from the gateway.
Design considerations behind the user cache:
* Explicitly handle deleted user IDs by short circuiting the lookup
logic and returning a singleton.
* The cache map is protected during HTTP requests to the Discord API.
* The nonexistence of a user is cached. This is to prevent excessive
requests (a user can't suddenly begin existing at a given ID).
The user cache is upserted on READY, incoming messages, backfill, etc.
In the same vein as mautrix-whatsapp, -slack and others, do not make
assumptions about how the ID is represented in the connector code. Let
the discordid package be entirely responsible.
For each guild specified in the config, create a space and bridge all
contained text channels that the user has permissions to view.
* Finally add a custom config struct where we accept a list of guild IDs
to bridge. This is intended to be temporary as we flesh out the proper
interfaces for managing which guilds to bridge.
* Defined a custom meta type for portals that holds the containing guild
ID of the channel (if any).
* Transferred the responsibility of building a channel's ChatInfo and
ChatMemberList to the DiscordChatResync event itself.
This method only has heartbeat session population logic for now, so it's
actually a no-op during provisioning. However, there's probably some
value in "mandating" that clients call this shortly after construction,
so we have a chance to run any setup logic that we might need in the
future.
This _feels_ unidiomatic...?
