Merge pull request #84 from anross/devel

[releng] Added requires for adaptor package
Move obix_get_timestamp from client library to common library

Rename obix_get_timestamp() to get_utc_timestamp() since it invokes
gmtime_r() to convert calendar time into UTC based struct tm, and
move it from the obix-client library to obix-common library so as
to be used by test tools without having to link up with obix-client
library which requires libcurl as well.

Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com>
Signed-off-by: Qingtao Cao <harry.cao@nextdc.com>
Move the inclusion of XML headers from obix_utils.h to xml_utils.h

This frees obix_utils.h from XML headers so that test tools can
manipulate libobix-common without having to link up with libxml2.

Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com>
Signed-off-by: Qingtao Cao <harry.cao@nextdc.com>
Support ISO-8601 timestamp format

Support the timezone designator in the timestamp string according to
the ISO-8601 standard.

If no timezone designator is available, then it will be regarded as in
UTC timezone. Other valid format includes the following:
 . "Z"
 . "+/-hh", where "hh" must be 2 digits no larger than 12;
 . "+/-hhmm", where "hh" must be 2 digits no larger than 12 and
   in theory "mm" must be no larger than 59. In particular, if "hh"
   equals to 12 then "mm" must be "00"

It's worthwhile to note that the current strptime() API implementation
has adopted practical compromise from the timezone definition as in
ISO-8601, for example:
 . no colon supported. At most 4 digits will be consumed after the "+/-"
   offset character. Moreover, if it encounters any non-digit character,
   it stops parsing the rest of timezone string;
 . the "mm" value will not always be treated as "minutes" as expected
   by user. In theory, it must be a multiple of 3. In practice, it should
   be a multiple of 15.

Please refer to docs/timezone.md file for details.

Also included is a test case to demonstrate all the tricks on timestamp
strings and relevant test results.
Fix a misuse of function pointers

Function names themselves are the entry point or address of their
bianry code, therefore function names themselves are function
pointers already, the same as array names.

As a result, a function name instead of its address should be
directly assigned to another function pointer.
Sanity check on the "-n" option of the historyQuery handler

The oBIX server can't take it for granted that "-n" option carries
a positive value. In previous implementation, if "-n 0" is passed
then the logic in historyQuery handler flows until segfaults.

Therefore negative values or zero value should be handled carefully.
For sake of convenience of oBIX clients, if no "-n" option or a
negative value such as "-1" is used, then all existing records are
considered. Furthermore, if "-n 0" is used, then the handler returns
the timestamps for the first and last records for relevant device so
that oBIX clients can get the end timestamp conveniently instead of
having to query all existing records.
Improve how the end timestamp of a history facility is fetched.

Instead of requesting the whole index file of a history facility and
move on to the abstract of the last history raw data file in order to
get the end timestamp of it, the newly supported "-n 0" option of the
historyQuery handler can be manipulated to return the start and end
timestamp of a history facility directly.
Update the path of configuration files in a couple of .md documents

Update the path of configuration files according to the current status
of the ONEDC/obix.git repo, also fix the name of the generic configuration
file with an oBIX server that can be utilised by different adaptors.
Appended history record's timestamp must be newer than the last one

According to the oBIX spec, the newly appended history records must
not include a timestamp older than or equal to that of the last one.
Impose more stringent checks on the timestamp of an incoming record
and skip it over if its timestamp does not relatively newer.
fixed sleep in the wrong place in the long poll unit test
Supplement notes about the robustness of C timestamp APIs

Add some examples and notes about when C timestamp APIs, strptime()
and timegm(), can tolerate invalid values in a timestamp string or
treat them as zero or return an error code.

This helps understanding why history handlers sometime may complain
about the given record includes a timestamp in the past, which may
also be attributed to invalid values.
Merge pull request #86 from Qingtao-Cao/devel

Support timezone designator in timestamp string - fix Issue#58 - 5th try