Triage ping for jkrcal@: do we plan to address this anytime soon?

If not, we may want to adjust to P3.

Adjusted to M73. It is on the cleanup hotlist so there is still some chance this gets addressed :)

Some thoughts:
- I'd rather avoid extending the bridge's API (but removing methods sounds good!).
- Rejecting incremental updates for wallet should be trivial because ApplySyncChanges() could do that (vs MergeSyncData()).
- The opposite is more problematic: regular bridges don't support full updates and shouldn't IMO need to bother with the idea of MergeSyncData() potentially being called twice.

Outcomes from an offline discussion with mastiz@: closing the bug as we see no strictly better implementation than the today's.

Rationale: checking that a regular Bridge does not receive a full update feels important and we do not want to put responsibility for this on all bridges (and there does not seem to be any simple way to do it in the base class).

We considered several alternatives:
  1) Replace the SupportsIncrementalUpdates() function by the ApplyFullUpdate() function. The default implementation of all three update functions (MergeSyncData, ApplySyncChanges, ApplyFullUpdate) would raise errors. Each bridge would override those that it needs and naturally not raise errors there. Not choosing this alternative as it is not much better than the current situation and it would slightly complicate the code in the ClientTagBasedModelTypeProcessor.
  2) Implement full updates by Stopping the datatype and starting it again (followed by MergeSyncData). This would make the full updates fit the regular flow.
However, it does not work well for the only user, WALLET_DATA, as it would send two notifications to PersonalDataManager forcing it to reload its data twice from the DB.

Florian, if you disagree, feel free to reopen the bug.