Use the backend's native modify timestamp if available

[ralflang]

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.

[mrubinsk]

I see an issue with the fact that the synchronization related API calls Turba_Api::getChanges(), Turba_Api::getChangesByModSeq(), Turba_Api::listBy() etc... all use the Horde_History system to determine changes. The lastModification value on the Turba_Object itself is not used. While this might work for CalDAV only I can foresee the possibility of some race condition where the state of the data becomes inconsistent.

...and yes, I know how long it's been since this was opened :) Better late than never.

[ralflang]

Good points though Michael. I will need to consult with colleagues how to avoid this gap.