Do not render already spooled messages

At the moment our message-sending function is triggered off new Firestore documents. This means that, when creating a message in the spool, it should already have its contents rendered and supplied. That's fine for messages triggered off subscriptions for the first time, but it also means that we have to render the messages every time they're triggered again. E.g. after a subscription is triggered by the first failed build or test, it will keep triggering off all the subsequent ones, and keep rendering those messages. It's not such a big deal with the current (very simple) ORM prefetching/caching scheme, but we're still wasting CPU and memory, and eventually might run into trouble with SQL query quota too.

An earlier attempt to fix this in b1d916642876d5d16869f6b41219f0158a237652 was just reverted in 6c7aa0aa726a4a943ff2a47da47424235f76034b. We need to think of something better. E.g. doing it in two steps as in b1d916642876d5d16869f6b41219f0158a237652 and adding another message queue for triggering sending, but perhaps something better could be found.

Start with the message-sending function and the Firestore-triggered spool flow. Compare the earlier approach in commits b1d916642876d5d16869f6b41219f0158a237652 and 6c7aa0aa726a4a943ff2a47da47424235f76034b, then determine a design that avoids rendering already-spooled messages. Done means repeated subscription triggers do not re-render existing messages while sending still works.