refactor/data-manager-communities-channels

[samthomson]

This gimega PR refactors data fetching throughout the app, into a parent data provider. This allows for some upfront loading, centralised caching, and thus improved performance throughout the app. It's the necessary foundation, to build a real time app on top of.
The goal here was to keep all functionality exactly the same, just move data fetching/updating to one dedicated place. However I did discover quite a few bugs, so fixed them as I went. I also refactored various UI components, to aid reusability and allow for better data flow (eg prop drilling to dumb components over unnecessary hooks). These changes although making for many diffs, are minor imo. The big change is just one: moving all communities data (and derived channels, messages, reactions, permissions, pinned messages, member events etc) up to the data manager provider - plus keeping subscriptions open in order to catch all relevant future events.

It's not perfect, there will likely be some loose ends to tie up, but I'm confident the benefits vastly outweigh any short term hiccups, and we can continue forward with this data architecture to build a nicer UX.

Some things I didn't address:

• We have an interesting ontology between events enabling them to relate. channels relate to communities, and messages in those channels relate to the channel definition event. However they don't use the event ids, but slugs of the community or channel name. This ought to be improved so that data won't get lost/orphaned if a community/channel is renamed.
• In some cases quirky patterns for a 'latest' event were used instead of addressable events.
• Every community has an artificial 'general' channel. This could be created explicitly when a community is created. For now we have lots of code workarounds due to this.
• There is no advanced network error handling (eg wifi disconnected, or user changes tab and the browser restricts network access completely or somewhat, etc) and restarting of subscriptions and querying to backfill data.

I chose for now to maintain backwards compatibility - and just change one big thing at a time. Fixing the above will mean starting over in terms of data in our communities. Thus, the sooner the better - and for now treat everything as disposable/ethereal.
I think this is OK, as ultimately we'll want to rewrite everything in a while anyway 😄 to have real private communities and not pseudo privacy/permissions. Now we're in our prototype / proof of concept context, as I see it.

Visually this PR won't look much different. Although if you open another browser/burner to test with, and send messages in a channel you'll see them appear instantly. You can also test creating a new channel and seeing it appear in the other browser. Likewise try creating a community in one browser, then try to join in the other - you'll see the first browser instantly has a membership request, which when approved, lets the other browser see the community in full.

I also added this relay subscription indicator. For sure we may want to design something different, but I thought conveying the connectivity was relevant, as if a subscription drops the user is left out of date but doesn't know it. (it's at least handy for us devs for now...)

What I would like to do later:

• Refactor the DataManagerProvider to contain two distinct providers - one for Messaging, and one for Communities. Maybe even more. Also refactor the hooks and reusable code here. Basically this file is one gigantic "let's put everything in here and get it working" effort, but once it's working Ok - could be structured better.
• As mentioned above:
  • Change the data ontology on how events relate to each other
  • Get rid of synthetic general channels - just explicitly create one when we create a community.
  • use addressable events for channel permissions.
• 'seen' / 'new' state for communities / channels, for when there's a new message. Although this can be separate from the data layer per se.
• Go back through all the community settings and community join/invite/membership UXs. We have a lot of legacy stuff (and maybe initial vibe code fluff) which now we have a clearer idea for join UXs, we can refactor considerably.
• ten million other things, but not related to the above - they can be separate issues against other milestone tasks, or come after.