Do not ship rsyslog on Jessie

We now have the Journal, which is way more powerful => do we need to keep rsyslog?

Dropping it has a few advantages:

• less memory wasted (both for the process and for the data we’re currently storing twice)
• more reliable logs: I’ve just tried to debug #8710 (closed) and… realized that the very messages I was looking for were neither in syslog nor in the journal, due to rsyslog dropping stuff whenever it’s arriving too fast…

So, what would be broken if we did drop rsyslog?

• tails-restricted-network-detector basically does tail -f | grep, with some refinements; using journalctl -u NetworkManager.service would avoid having to look at all log lines; the rest would likely be very similar
  • the cheapest solution may be to keep rsyslog, but configure it to save to disk only the info needed by tails-restricted-network-detector: we still would get a mostly useless daemon running, and journald forwarding all messages to it, but at least it won’t eat precious memory to store too much duplicated info on “disk”
  • journalctl’s json output, combined with jq, might be useful: then the “parser” only gets the fields it needs, and since all the complexity was removed already, it could even be written in POSIX shell to same some RAM. E.g. journalctl --unit=NetworkManager.service --output=json-pretty --follow | jq --monochrome-output --unbuffered --raw-output '.MESSAGE' outputs a stream with only the field we’re interested in.
• DONE tails-debugging-info greps /var/log/messages => would be nicer, and more accurate, using journalctl
• DONE tails-debugging-info cat’s some log files that are now fed into the Journal => can use journalctl instead

Related issues

• Related to #7986 (closed)

Original created by @intrigeri on 8320 (Redmine)