Allow sync operations to modify the sync filter

[bjester]

Current behavior

Currently, a sync context strictly refuses to be updated with a new sync filter via .update() when it has already been configured with one. Also, when a client uses a sync controller for managing a sync, the controller may pass a 'prepared context' to the sync operations that may be a different object than used during other parts of the sync operation (local versus remote). For example, if a network operation updates the filter on the context, subsequent local operations will not receive the updated filter because the controller uses a composite filter for parity between local and remote syncs.

Desired behavior

The context classes should allow the sync_filter to be updated, if and only if:

• the filter has changed
• the sync is still within the initialization stage (prior to the update)
• the old filter is still a subset of the new filter

When a context receives an acceptable new sync_filter, it should:

• save it on itself, and any child contexts (see CompositeSessionContext)
• update the filter on the TransferSession and save it

The context classes should have a new method .join(context) that can allow contexts that had been previously returned from .prepare() to receive those contexts back:

• for all but the CompositeSessionContext, this should be a no-op because .prepare() returns itself
• for CompositeSessionContext, this should call .update(sync_filter=prepared_context.filter) to implement desired functionality

The SessionController should call the new method above after it invokes middleware (operations) and receives a result.

Value add

Allows implementors of Morango, like Kolibri, to implement dynamic partition filtering by modifying the context during the initialization stages of the sync.

Possible tradeoffs

Implementations using this functionality could add complexity to the existing partitioning, filtering, and certificate scope verification.