Bug 5254, part 2: Rotate master process' cache.log

[rousskov]

Before these changes:

• Bug 2727: Master process kept the original cache.log open forever, resulting in that file lurking in the filesystem for as long as a Squid instance runs, despite log rotations that delete it.

• Bug 3640: Multiprocess Squid instances rotated cache.log K times per single "squid -k rotate" event, where K is the number of all Squid kids: workers, diskers (if any), and Coordinator (if any). Admins saw the expected number of rotations only for K=1 instances (workers=1, no diskers, and, hence, no Coordinator) -- a lucky accident.

After these changes:

• Master process rotates its cache.log. The original file can be fully deleted after the first rotation.

• Squid rotates cache.log 1+K times per "squid -k rotate". The additional rotation is performed by the master process itself. Admins never see the expected number of rotations.

Thus, this change makes things better for K>1 configurations, but makes things partially better/worse for K=1 configurations. All configurations remain broken.

A supported workaround is to use external filename rotation. Each Squid process closes and reopens the cache_log file: logfile_rotate 0

An unsupported workaround is to configure each process to have its own cache.log. For example: cache_log cache-${process_number}.log

Both workarounds rely on these code changes, the Bug 5254 p1 fix, and absence of helpers (which also keep a cache.log descriptor).

[rousskov]

S-waiting-for-PR: The full effects described in this PR assume that #1222 fix has been merged. This PR changes work fine without that PR, but the cache.log file will remain lurking in the filesystem until both PRs are merged.

[yadij]

I have updated the description with bug references. If possible please separate the fixes into two PR.