Introduce a method for fully automated data replication of small data sets

[GeraldKrause]

Today, OData V4 supports automated data replication that scales for large data sets:

1. A client can request the server to track changes and return a delta link to retrieve changes with a subsequent request to this delta link.
2. To automate this process, the client can provide a callback URL in the delta request to be invoked by the server when a data change occurred.

Implementing change tracking comes with the complexity to calculate new and deleted entities based on the underlying internal data structures, for example by comparing before and after images. Spending such an implementation effort is hard to justify for services with entity sets which are known to have a small size. There, it is sufficient from performance perspective to query the entire set again after a change occurred. This repeated execution of queries at the right time can be automated if the server sends a notifications about a change.

Therefore, the proposal is to add a new preference callback-on-change with a URL as argument: Prefer: callback-on-change; url="<uri>"

This new callback-on-change preference differs from the preference track-changes or the combination of track-changes and callback (as requested in issue #1961). The preference callback-on-change only informs the client about the fact that a change occurred, whereas the other preferences also deal with the actually changed entities.

GET requests to an entity set may include this preference to specify that the service shall call the URL when the entity set is changed after this request by adding, updating, or removing an entity. If supported for the request, the service MUST include a Preference-Applied header in the response for the callback-on-change preference and remembers the callback URL to invoke it on the next change to the entity set. For HTTP based callbacks, the service executes an HTTP GET request against the specified URL.

For paged results, the preference MUST be specified on the initial request. Services MUST ignore the callback-on-change preference if applied to the next link.

The callback-on-change preference SHOULD NOT be applied to a batch request, but MAY be applied to individual requests within a batch.

This new preference should be complemented with a new ChangeCallback term in the Capabilities vocabulary. Services advertise their capability to callback on a change by annotating entity sets with this term.

[ralfhandl]

Could probably covered with existing preference callback without adding a new preference.