Instead, give a %no-mail response message. It's not entirely unexpected
to encounter ships that don't have a hosting account email address
associated with them, so it shouldn't be a reason to crash.
The crash is particularly problematic because as of the previous
commits, we now actually show the trace of thread crashes.
We weren't accounting for the different wire used for this, causing us
to spill our spaghetti and redirect processing to +on-fail, which wasn't
very graceful.
Now, we can actually properly notify on failed thread runs.
There is a (somewhat poorly understood) case where the group associated
with a chat may not actually contain that chat in its channels listing.
Here, instead of assuming the channel is always present, we ask for it
more gently, and simply skip to the next-most-active channel if it turns
out to be missing.
We also remove a stray debug printf, and add a trace print in case
anything else goes wrong here.
The "save summary" thread still had hark flagged as one of its dependencies,
but doesn't actually use that for anything anymore.
Here we simply remove the import.
Includes the bark/growl system for sharing activity summaries. The growl
agent respects the "activity logging" consent flag used by groups,
defaults to not sharing if that flag is not set, and only shares with
the "bark host" when prompted. (The bark host, in turn, currently only
stores responses for hosted ships.)
Also includes all the groups-side dependencies this has, which it needs
for the chats & groups types. Hard-including those files will save us
some run-around during deploy.
Co-authored-by: midsum-salrux <nathan@tlon.io>
Sending on-demand emails requires a Mandrill API key, not a Mailchimp
one. (They're part of the same company/suite now, but still use
different keys and endpoints. Mandrill and Mailchimp keys are also
called "mailchimp" and "marketing" keys respectively. Yes, in that
order.)
