MFC r318960,r319545,r319546,r319548,r321261:

r318960 (by dab):

Add newsyslog capability to write RFC5424 compliant rotation message.

This modification adds the capability to newsyslog to write the
rotation message in a format that is compliant with RFC5424. This
capability is enabled on a per-log file basis through a new value
("T") in the flags field in newsyslog.conf. This is useful on systems
that use the RFC5424 format for log files so that the rotation message
format matches that of the other log messages. There has been recent
mention of adding an RFC5424 compliant mode to syslogd and at least
one alternative system log daemon (rsyslogd) that already has the
capability to use that format.

Relnotes: yes

r319545:

Don't execute the TODO cases in a subshell

This messes up the testcase counter, as seen in bug 219756.

PR: 212160, 219756

r319546:

Fix the testplan after ^/head@r318960

The number of executed testcases is 128, not 126.

MFC with: r318960

r319548:

Remove TODO for sub testcases added for bug 212160

On closer inspection, the past failures no longer occur on ^/head.

PR: 212160

r321261:

Clean up leading whitespace (convert single column spaces to hard tabs)

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Drop the include for <stdint.h>, it was only needed when this was
using __DECONST() for something, and that reference has been removed.

Noticed by: Helge Oldach
MFC after: 13 days

Handle a 'const' parameter without using __DECONST().

MFC after: 14 days

Restructure the time processing routines, mainly to fix up the
"will trim at" message printed when the user requests '-v'. The
previous code would often print the wrong time, such as:
On Sept 22, run: newsyslog -nv /var/log/wtmp
And see: will trim at Mon Sep 1 05:00:00 2003
correct msg: will trim at Wed Oct 1 05:00:00 2003

MFC after: 20 days

Correct the calculation of "a leap year" in parseDWM. The calculation
would only match a leap year every 400 years. The parseDWM code first
showed up in April 2000, so the first time this bug would cause any
confusion is in Feb 2004.

MFC after: 18 days

Move the parse8601 and parseDWM routines into a new ptime.c file. The
only code-change is to add a "next_time" parameter to both routines (and
that is not used yet). A later update will make "next_time" more useful.

MFC after: 20 days