compose fade: Extract compose_fade_users class.

We extract compose_fade_users and compose_fade_helper.

This is a pretty verbatim extraction of code, apart from adding a few
exports and changing the callers.

This change makes the buddy_data module no longer sit "above" these
files in the dependency graph (at least not via compose_fade):

    * jquery
    * lodash (not a big deal)
    * compose_state
    * floating_recipient_bar
    * message_viewport
    * rows

The new moules have dependencies that buddy_data already
had directly for other reasons:

    * people
    * util

And then buddy_data still depends on stream_data indirectly through
the compose-fade logic for stream_data. Even without compose-fade, it
would depend indirectly on stream_data via hash_util.

Note that we could have lifted the calls to compose_fade out of
buddy_data to move some dependencies around, but it's useful to have
buddy_data fully encapsulate what goes into the buddy list without
spreading responsibilities to things like activity.js and
buddy_list.js. We can now unit-test the logic at the level of
buddy_data, which is a lot easier than trying to do it via modules
that delegate drawing or do drawing (such as activity.js and
buddy_list.js).

Note that we still don't have 100% line coverage on the
compose_fade.js module, but all the code that we extracted now is
covered, mostly via buddy_data tests.

static/js/compose_fade_helper.js

@@ -0,0 +1,59 @@
+import * as stream_data from "./stream_data";
+import * as util from "./util";
+
+let focused_recipient;
+
+export function should_fade_message(message) {
+    return !util.same_recipient(focused_recipient, message);
+}
+
+export function clear_focused_recipient() {
+    focused_recipient = undefined;
+}
+
+export function set_focused_recipient(recipient) {
+    focused_recipient = recipient;
+}
+
+export function would_receive_message(user_id) {
+    if (focused_recipient.type === "stream") {
+        const sub = stream_data.get_sub_by_id(focused_recipient.stream_id);
+        if (!sub) {
+            // If the stream isn't valid, there is no risk of a mix
+            // yet, so we sort of "lie" and say they would receive a
+            // message.
+            return true;
+        }
+
+        return stream_data.is_user_subscribed(focused_recipient.stream_id, user_id);
+    }
+
+    // PM, so check if the given email is in the recipients list.
+    return util.is_pm_recipient(user_id, focused_recipient);
+}
+
+export function want_normal_display() {
+    // If we're not composing show a normal display.
+    if (focused_recipient === undefined) {
+        return true;
+    }
+
+    // If the user really hasn't specified anything let, then we want a normal display
+    if (focused_recipient.type === "stream") {
+        // If a stream doesn't exist, there is no real chance of a mix, so fading
+        // is just noise to the user.
+        if (!stream_data.get_sub_by_id(focused_recipient.stream_id)) {
+            return true;
+        }
+
+        // This is kind of debatable.  If the topic is empty, it could be that
+        // the user simply hasn't started typing it yet, but disabling fading here
+        // means the feature doesn't help realms where topics aren't mandatory
+        // (which is most realms as of this writing).
+        if (focused_recipient.topic === "") {
+            return true;
+        }
+    }
+
+    return focused_recipient.type === "private" && focused_recipient.reply_to === "";
+}