The json serialization logic hadn't been updated correctly. We leave a
better comment for easier reference. And we want more details to look at
in the case something errors out.
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.
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.)
Successfully sent an email like so:
```hoon
=vars `(map @t @t)`(malt ~[['name' 'john'] ['notifications' '1337']])
```
```
-bark!mailchimp-send-template "[KEY]" "tom@tlon.io" "landscape-weekly-digest" vars
```
TODO: handle the `vars` map
