syslog: fixes and updates to rsyslogd and logrotate.
Adjust lograte size to prevent a mismatch.
Change rsyslogd size to be actual size instead of a naive value.
Potentially fix bug #13699000 by increasing the maximum number of TCP sessions.

Rsyslog was rejecting agents from connecting because of MaxSessions, which caused those
agents to go into spirals of trying to restart their rsyslog worker over and over,
which then generated tons of DEBUG level logging on machine-0 because of the workers
restarting, which then spammed the log file a lot.
Merge branch 'master' into rsyslog-max-connections-1369900

Small conflict that can be trivially fixed.

Conflicts:
	utils/syslog/config.go
extract relation membership caching into new type; not hoked up yet
extract relation membership caching into new type, which I remembered to add this time; not hooked up yet
figured out better interface
RelationContext now uses cache internally; uniter now hooked up and tested; context tests not yet updated
Update charm interface implementation.
fixed some tests, commented out others, will reinstate soon
add missing test case
reinstate, expand factory tests to take caches into account
reinstate and slightly extend relevant tests; drop an irrelevant one
address review
address review
Merge branch 'master' into rsyslog-max-connections-1369900
Update the testing template to include the new line.
Merge pull request #785 from jameinel/rsyslog-max-connections-1369900

Increase the maximum number of rsyslog connections

see http://reviews.vapour.ws/r/54/

Some of this change includes wwitzel's improvements for logrotate, and can be ignored. I'll refresh the diff when his patch lands.
Force the requests to actually be concurrent by adding a Barrier.

The code wanted to make sure that we would have concurrent requests to Put, so we make sure to
pause Put() until all of the requests have been started.
Adding a time.Sleep(10ms) to the goroutine loop causes it to fail reliably (because the
goroutines end up effectively serialized), but if we add the putBarrier it makes them
concurrent again even with the sleeps.
go fmt
Merge pull request #997 from jameinel/fix-charm-concurrently-test

Force the requests in TestAddCharmConcurrently to actually be concurrent by adding a Barrier.

The code wanted to make sure that we would have concurrent requests to Put, so we make sure to
pause Put() until all of the requests have been started.
Adding a time.Sleep(10ms) to the goroutine loop causes it to fail reliably (because the
goroutines end up effectively serialized), but if we add the putBarrier it makes them
concurrent again even with the sleeps.