Flume fix part 2: avoid using flume in a couple of cases, and revert attempted fix#1 (#396)

* A second attempt to avoid the flume memory leak, since the first didn't actually work

* No luck with second flume fix, so revert to futures::mpsc in a few places)

* cargo fmt

* Add a comment to cover use of into_stream

backend/telemetry_core/src/main.rs

@@ -353,8 +353,13 @@ where
 {
     // unbounded channel so that slow feeds don't block aggregator progress:
     let (tx_to_feed_conn, rx_from_aggregator) = flume::unbounded();
-    let mut rx_from_aggregator_chunks =
-        ReadyChunksAll::new(common::flume_receiver_into_stream(rx_from_aggregator));
+
+    // `Receiver::into_stream()` is currently problematic at the time of writing
+    // (see https://github.com/zesterer/flume/issues/88). If this stream is polled lots
+    // and isn't ready, it'll leak memory. In this case, since we only select from it or
+    // a close channel, we shouldn't poll the thing more than once before it's ready (and
+    // when it's ready, it cleans up after itself properly). So, I hope it won't leak!
+    let mut rx_from_aggregator_chunks = ReadyChunksAll::new(rx_from_aggregator.into_stream());
 
     // Tell the aggregator about this new connection, and give it a way to send messages to us:
     let init_msg = FromFeedWebsocket::Initialize {