Gracefully handle cases when logging exchange does not exist

Client test suites that test connection recovery by
restarting RabbitMQ ocassionally lead to a situation when
amq.rabbitmq.log in the "/" vhost can be unavailable for a split
second.

Default vhost may or may not exist in general. So handle {error, not_found}
responses from rabbit_basic:publish/4 instead of potentially seriously
polluting logs with confusing exceptions.

While at it, return a sensible value from terminate/2.

Stop match earlier, and added some comments

Remove systemd dependency on syslog target

Neither rabbitmq nor any dependent services in chain actually relies on
syslog, so why keep it?

This tested in Fedora since 2016-01. See this commit:

http://pkgs.fedoraproject.org/cgit/rpms/rabbitmq-server.git/commit/?id=1477671

Nobody complained so far.

Signed-off-by: Peter Lemenkov <[email protected]>

Merge pull request rabbitmq#798 from rabbitmq/rabbitmq-server-546

Bump minimal required version to 18.3

(c) year

Merge pull request rabbitmq#773 from rabbitmq/rabbitmq-server-772

Add log information during the network_partition

Merge pull request rabbitmq#773 from rabbitmq/rabbitmq-server-772

Add log information during the network_partition

Merge branch 'stable'

Merge pull request rabbitmq#722 from rabbitmq/rabbitmq-auth-backend-l…

…dap-13

Include vhost to direct connection authentication properties.

Merge pull request rabbitmq#762 from bogdando/bug/1541471

Stop process when rabbit is running but is not connected to master.