fix(notifications): default templates and logic

[piksel]

Follow up/continuation of #981.

This PR will fix the default report template to only output something if Updated or Failed is non-zero. It also fixes the non-session notifications (like the startup info) which was just broken using the report notifications.
Note that this aligns the notification behaviour roughly with how it works using legacy notifications, as no notifications will be sent when everything is "normal"/already updated.

the new default report template

{{- if .Report -}}
  {{- with .Report -}}
    {{- if ( or .Updated .Failed ) -}}
{{len .Scanned}} Scanned, {{len .Updated}} Updated, {{len .Failed}} Failed
      {{- range .Updated}}
- {{.Name}} ({{.ImageName}}): {{.CurrentImageID.ShortID}} updated to {{.LatestImageID.ShortID}}
      {{- end -}}
      {{- range .Fresh}}
- {{.Name}} ({{.ImageName}}): {{.State}}
      {{- end -}}
      {{- range .Skipped}}
- {{.Name}} ({{.ImageName}}): {{.State}}: {{.Error}}
      {{- end -}}
      {{- range .Failed}}
- {{.Name}} ({{.ImageName}}): {{.State}}: {{.Error}}
      {{- end -}}
    {{- end -}}
  {{- end -}}
{{- else -}}
  {{range .Entries -}}{{.Message}}{{"\n"}}{{- end -}}
{{end -}}

To prevent the notifications from being sent, it skips notifications whenever the output of the template (whether legacy or report templates) is an empty string.
This fixes #1008

It also adds a "special" data field for logging that just marks a message as non-notification. This is so that we can still log using the appropriate log levels without having to worry about it getting sent as notifications.
This mainly concerns logs about the notifications themselves, which would cause loops etc.
Any log messages with the field notify set to no is ignored.

[codecov]

Codecov Report

Merging #1010 (bdc267b) into main (ea300b7) will increase coverage by 0.17%.
The diff coverage is 61.90%.

@@            Coverage Diff             @@
##             main    #1010      +/-   ##
==========================================
+ Coverage   59.63%   59.80%   +0.17%     
==========================================
  Files          22       22              
  Lines        1412     1428      +16     
==========================================
+ Hits          842      854      +12     
- Misses        500      502       +2     
- Partials       70       72       +2     

Impacted Files	Coverage Δ
pkg/notifications/shoutrrr.go	74.35% <57.89%> (-1.03%)	⬇️
pkg/notifications/notifier.go	70.21% <100.00%> (+0.64%)	⬆️
pkg/registry/digest/digest.go	44.26% <0.00%> (+1.88%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea300b7...bdc267b. Read the comment docs.

[piksel]

Also, this enables having the startup message being logged even if it's not wanted as a notification, it also changes said startup message to be a series of messages instead of a single one with newlines in it (which was not really supported in logfmt):

INFO[0001] Watchtower v0.0.0-unknown
INFO[0001] Using notifications: telegram
INFO[0001] Checking all containers (except explicitly disabled with label)
INFO[0001] Running a one time update.

They are still batched up and sent as a single notification, so there should be no difference in the notifications.

Also, this is how the closing messages look, no more raw printing to stdout:

DEBU[0002] No new images found for /testcontainer1
DEBU[0002] Session done: 1 scanned, 0 updated, 0 failed
INFO[0002] Waiting for the notification goroutine to finish  notify=no
INFO[0002] Skipping notification due to empty message    notify=no

And the same goes for notification errors when sending:

ERRO[0002] Failed to send shoutrrr notification          error="failed to send notification to \"xxxxxx\", response status code 401 Unauthorized" index=0 notify=no service=telegram

...and for template issues:

FATA[0001] Notification template error                   error="template: :1:3: executing \"\" at <.InvalidProp>: can't evaluate field InvalidProp in type notifications.Data" notify=no

[ilike2burnthing]

Is the Docker log supposed to look like this when no notifications are configured?

time="2021-09-21T18:46:22Z" level=info msg="Skipping notification due to empty message" notify=no
time="2021-09-21T18:47:21Z" level=info msg="Skipping notification due to empty message" notify=no
time="2021-09-21T18:48:21Z" level=info msg="Skipping notification due to empty message" notify=no

(changed the poll interval to 60 to test if it was related to the timing of the log entries)

[piksel]

Sort of. It's not really necessary when you don't have any notifications of course...

[ilike2burnthing]

Any way to disable it?