Rename "channels" to "conversations."

The term "channel" for a conversational container has a long and storied history, but is mostly evocative of IRC and of other, ah, "nerd-centric" services. It does show up in more widespread contexts: Discord and Slack both refer to their primary conversational containers as "channels," for example. However, I think it's unnecessary jargon, and I'd like to do away with it.

To that end, this change pervasively changes one term to the other wherever it appears, with the following exceptions:

* A `channel` concept (unrelated to conversations) is also provided by an external library; we can't and shouldn't try to rename that.
* The code to deal with the `pilcrow:channelData` and `pilcrow:lastActiveChannel` local storage properties is still present, to migrate existing data to new keys. It will be removed in a later change.

This is a **breaking API change**. As we are not yet managing any API compatibility promises, this is formally not an issue, but it is something to be aware of practically. The major API changes are:

* Paths beginning with `/api/channels` are now under `/api/conversations`, without other modifications.
* Fields labelled with `channel…` terms are now labelled with `conversation…` terms. For example, a `message` `sent` event is now sent to a `conversation`, not a `channel`.

This is also a **breaking UI change**. Specifically, any saved paths for `/ch/CHANNELID` will now lead to a 404. The corresponding paths are `/c/CONVERSATIONID`. While I've made an effort to migrate the location of stored data, I have not tried to provide adapters to fix this specific issue, because the disruption is short-lived and very easily addressed by opening a channel in the client UI.

This change is obnoxiously large and difficult to review, for which I apologize. If this shows up in `git annotate`, please forgive me. These kinds of renamings are hard to carry out without a major disruption, especially when the concept ("channel" in this case) is used so pervasively throughout the system.

I think it's worth making this change that pervasively so that we don't have an indefinitely-long tail of "well, it's a conversation in the docs, but the table is called `channel` for historical reasons" type issues.

Merges conversations-not-channels into main.

1 files changed, 22 insertions, 21 deletions

diff --git a/src/event/handlers/stream/test/resume.rs b/src/event/handlers/stream/test/resume.rs
index 835d350..a0da692 100644
--- a/src/event/handlers/stream/test/resume.rs
+++ b/src/event/handlers/stream/test/resume.rs
@@ -14,15 +14,16 @@ async fn resume() {
     // Set up the environment
 
     let app = fixtures::scratch_app().await;
-    let channel = fixtures::channel::create(&app, &fixtures::now()).await;
+    let conversation = fixtures::conversation::create(&app, &fixtures::now()).await;
     let sender = fixtures::user::create(&app, &fixtures::now()).await;
     let resume_point = fixtures::boot::resume_point(&app).await;
 
-    let initial_message = fixtures::message::send(&app, &channel, &sender, &fixtures::now()).await;
+    let initial_message =
+        fixtures::message::send(&app, &conversation, &sender, &fixtures::now()).await;
 
     let later_messages = vec![
-        fixtures::message::send(&app, &channel, &sender, &fixtures::now()).await,
-        fixtures::message::send(&app, &channel, &sender, &fixtures::now()).await,
+        fixtures::message::send(&app, &conversation, &sender, &fixtures::now()).await,
+        fixtures::message::send(&app, &conversation, &sender, &fixtures::now()).await,
     ];
 
     // Call the endpoint
@@ -75,8 +76,8 @@ async fn resume() {
 
 // This test verifies a real bug I hit developing the vector-of-sequences
 // approach to resuming events. A small omission caused the event IDs in a
-// resumed stream to _omit_ channels that were in the original stream until
-// those channels also appeared in the resumed stream.
+// resumed stream to _omit_ conversations that were in the original stream
+// until those conversations also appeared in the resumed stream.
 //
 // Clients would see something like
 // * In the original stream, Cfoo=5,Cbar=8
@@ -84,8 +85,8 @@ async fn resume() {
 //
 // Disconnecting and reconnecting a second time, using event IDs from that
 // initial period of the first resume attempt, would then cause the second
-// resume attempt to restart all other channels from the beginning, and not
-// from where the first disconnection happened.
+// resume attempt to restart all other conversations from the beginning, and
+// not from where the first disconnection happened.
 //
 // As we have switched to a single global event sequence number, this scenario
 // can no longer arise, but this test is preserved because the actual behaviour
@@ -97,8 +98,8 @@ async fn serial_resume() {
 
     let app = fixtures::scratch_app().await;
     let sender = fixtures::user::create(&app, &fixtures::now()).await;
-    let channel_a = fixtures::channel::create(&app, &fixtures::now()).await;
-    let channel_b = fixtures::channel::create(&app, &fixtures::now()).await;
+    let conversation_a = fixtures::conversation::create(&app, &fixtures::now()).await;
+    let conversation_b = fixtures::conversation::create(&app, &fixtures::now()).await;
     let resume_point = fixtures::boot::resume_point(&app).await;
 
     // Call the endpoint
@@ -107,8 +108,8 @@ async fn serial_resume() {
 
     let resume_at = {
         let initial_messages = [
-            fixtures::message::send(&app, &channel_a, &sender, &fixtures::now()).await,
-            fixtures::message::send(&app, &channel_b, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_a, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_b, &sender, &fixtures::now()).await,
         ];
 
         // First subscription
@@ -148,11 +149,11 @@ async fn serial_resume() {
     // Resume after disconnect
     let resume_at = {
         let resume_messages = [
-            // Note that channel_b does not appear here. The buggy behaviour
-            // would be masked if channel_b happened to send a new message
+            // Note that conversation_b does not appear here. The buggy behaviour
+            // would be masked if conversation_b happened to send a new message
             // into the resumed event stream.
-            fixtures::message::send(&app, &channel_a, &sender, &fixtures::now()).await,
-            fixtures::message::send(&app, &channel_a, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_a, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_a, &sender, &fixtures::now()).await,
         ];
 
         // Second subscription
@@ -190,12 +191,12 @@ async fn serial_resume() {
 
     // Resume after disconnect a second time
     {
-        // At this point, we can send on either channel and demonstrate the
-        // problem. The resume point should before both of these messages, but
-        // after _all_ prior messages.
+        // At this point, we can send on either conversation and demonstrate
+        // the problem. The resume point should before both of these messages,
+        // but after _all_ prior messages.
         let final_messages = [
-            fixtures::message::send(&app, &channel_a, &sender, &fixtures::now()).await,
-            fixtures::message::send(&app, &channel_b, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_a, &sender, &fixtures::now()).await,
+            fixtures::message::send(&app, &conversation_b, &sender, &fixtures::now()).await,
         ];
 
         // Third subscription