[dev] Turba: Catch backend-supplied modifytimestamps, fix sync for sneaky updates

[Ralf Lang]

https://github.com/horde/turba/pull/4

Allow the backend to provide own modification timestamps.

The main target is the turba ldap driver, but implementation is driver
agnostic. There are two use cases:

  * Data is modified by backend without Horde knowing (i.e. some
    administrative 3rd party tool)
  * Data is modified by horde but in a different context. You have one
    addressbook where a user or delegate can see and write to many
    fields, including information intended for a restricted audience.
    That same ldap tree is exposed as a separate addressbook with a more
    limited set of fields for a wider audience. The updates of the user
    are correctly written to the history api for the original
    addressbook, but not for the public addressbook.

Both cases result in the same behavior:

  * Data is correctly shown in Horde.
  * Sync mechanisms like CalDAV retrieve the correct recent data on
    initial/full sync
  * Sync mechanisms will never notify clients about a change of the
    entry, thus the client may overlook changes on incremental/update syncs

This feature is opt-in, the code change will not modify existing
installations without further config.
The administrator has to actively configure a __nativemodified attribute
to benefit from backend's info.
If present and not null, the backend's info will be used and the history
API will not be queried or updated.

One could get almost the same effect by just mapping a __modified
attribute to "modifytimestamp". However, modifytimestamp is in a string
format, while turba's lastModification method is documented as returning
an integer timestamp.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537