Merge pull request #1938 from jimis/3.6.x

Audit getaddrinfo() uses for proper freeing, redmine #6539.
redmine6531: Fix some strings of 9s to be of sensible lengths.

We got weirdness on Solaris and Aches because integers were rejected
as invalid if they happened to exceed 1410065407 (0x540be3ff),
a.k.a. on(2014,8,6,6,50,7); which just happens to be an imminent date
we tried to use.  (Yes, imminent; month and day are zero-based, not
quite what one might have expected.)  We discovered this was the upper
bound for signed integers, 9999999999 (ten 9s), wrapped into a 32-bit
int's range.  The lower bound was eleven 9s, negated; and the range
for unsigned ints was from zero to this eleven 9s value, so we even
had inconsistency between the upper bound of signed int and the
matching bound for unsigned.  Head.  Desk.

At the same time, CF_HIGHINIT and CF_LOWINIT (were undocumented and)
had likewise different numbers of 9s to them.  This made no sense
either.  So I've amended the sequences of 9s so that: corresponding
bounds actually match; and the values that result are faithfully
represented as 32-bit int values.  I've also added relevant comments.
The use of strings of 9s as bounds remains eccentric, but at least
it's not brokenly so.

(cherry picked from commit 9a2b71fca2f124d6677c8ea44ee823e346e80031)
Truncate over-long strings of 9s.

We use long strings of 9s as bounding values for integers.  On 32-bit
values, if those long strings exceed 999999999 the resulting int wraps
and is smaller, so don't use more than nine 9s in a row.

In contrib/cfengine.el, avoid repetition of these strings of 9s by
defining two new constants for the ranges that involve them.

(cherry picked from commit 29d780c35b6d91e6e727a0ec54d3b8ec90004dfa)
Quote a value abused as a function in cfengine-mode's elisp.

M-x byte-compile-file (to check my 9s-fix was sound) revealed a use of
a string literal as a function, which it seemed likely was meant to be
a quoted value, so I did that.  There remain three unbound variable
reference grumbles from compilation, but I can't immediately see what
to do about them.

(cherry picked from commit ebc1ef0bcb7c0598a0979d36226bf9d0df7c5f15)
Ignore compiled emacs lisp files in contrib/.

(cherry picked from commit 0d6f8ffc44be9787515c52266ab8963464d5fac2)
Use a define consistently for all waiting for stop/exit.

(cherry picked from commit c402152ac4c4462a62389e11b00b0c0b9820542d)
Increase range of allowed integers to the full 32-bit range.

Narrowing to 999999999 made the range too small for time_t values
(e.g. the return from on(), which is what started all of this anyway)
that represent roughly the present time.  So expand the range as far
as we sensibly can, to the max ranges for signed 32-bit integers
(values are stored in int variables, even the CF_VALRANGE ones that
clearly think they're unsigned).

(cherry picked from commit 51b564c10971b9850d6a11bd144202006f7b3d82)
Follow-up revision of promise_knowledge.cf

Match the new ranges for integer values.

(cherry picked from commit fd56c04d990fd7778ea48fe4addc4bd2d922fa7d)
Notice and act on changes to call-collect reporting interval.

When we CheckFileChanges() we may pick up a change of policy that
changes this reporting interval; be sure to act on any such change.

(cherry picked from commit 1b1006865cd868ef65be297e8103e7c7c00cf895)
Carve up cf-serverd's StartServer() for readability.

The function had grown to over 200 lines; time for some housekeeping.
Broke out assorted chunks of it into local static functions, each
adequately self-contained, with names to make clear what's happening.

(cherry picked from commit 246632b7b2ced82d2de908e735097578730e5ce2)
Make clean-up of lock-specific policy unconditional.

There's a policy used solely as framework for the promise whose lock
ensures we don't have two of cf-serverd running at the same time.
This is entirely disconnected from the policy potentially used by
threads, so there's no need to protect its destruction from happening
while there are threads running; it can be deleted as soon as its lock
is released.

(cherry picked from commit b714f87c3825f4281e8a721ac2f6389893e99ff5)
Comment clarifications.

(cherry picked from commit ce0982b635142eac02cc37991a893604da6ac84e)
Initial changelog update for 3.6.2.
fix the insane limits of laterthan, max year 1000 makes it useless. Redmine #6530.

(cherry picked from commit 5262df056aba4db160cdafac0ce7a9a4b2387752)
Update changelog
join: Don't add delimiter if only null-values are left

Looks like a nested loop that introduces polinomial complexity,
but the inner loop advances the outer loop as well.

Fixes Redmine #6552
(cherry picked from commit db3ac8257edc35578e8124dab11891ce8a340076)
Changelog entry for 6552
Rename 'vbuff' to the more appropriate 'randfile'.

(cherry picked from commit 05aa9c7b1600734716a3aeaf25e3ccd102c3557f)
Restore support for denormal times in laterthan() and add it in on().

If someone specifies a date-and-time while adding an offset to one of
the components (e.g. to specify a given number of days, or hours,
after some specified event whose date and time are known) we can
handle that, doing The Right Thing (as handled by mktime, normalising
the date-time sensibly), by simply not forbidding it.  Recent changes
to laterthan() removed support for this; on() has not previously
supported it; but it makes sense to support it for both, so I'm
allowing both to take values in a wide (but still limited) range.
Also, move on()'s argument description to alongside those for the
other time-related functions with the same arguments.

(cherry picked from commit 465bdb874592a2c1fecfbdeb877bf6d678cb5d7e)
For vailidating input files we must use GetInputDIr(), because we can override its setting via configure options,
see https://dev.cfengine.com/issues/6551

(cherry picked from commit 56f40f470a213d816e09b10ad58c64285c6e4b84)