cc: #556

Channel.last_notify is the datetime of the most recent
notification sent via the channel. Channel.last_error is
the error message (blank if the delivery was successful).

In the integrations list, "Last Notification" column,
use these fields instead of looking up the most recent
Notification object. This saves some db queries,
and also fixes a subtle issue: if prunenotifications
cleans up all notifications for a given channel, the
"Last Notification" column would display "Never", which
would not be correct – not any more.

Fixes: #539

Fixes: #512

Fixes: #486

Fixes: #472

Fixes: #202

To send notifications, sendalerts calls Flip.send_alerts().
I updated Flip.send_alerts() to be a generator, and to yield
a (channel, error, send_time_in_seconds) triple per sent
notification.

With the previous 10 minutes / minute limit we were still hitting
Telegram API rate limit (the 429, "Too Many Requests" response)
from time to time.

Therefore, tighten the limit a bit on our side.

Fixes: #428

Fixes #455

Normally, when a webhook call fails (timeout, connection
error, non-2xx response), the HTTP request is retried up to two
times (so up to 3 times total). This is useful when sending
actual notifications, in case the webhook target has a temporary
glitch.

When interactively testing a webhook integration
("Send Test Notification" in the
"Integrations" page), we would prefer to see any errors ASAP
on the screen instead of retrying and so possibly swallowing them.

One specific use case is webhook targets that take long time to
generate a response. "Send Test Notification" is synchronous,
meaning that the user could be stuck for
5 x 3 = 15 seconds waiting for the  test HTTP request to time out
three times.