What action should Replication Filters apply to?

Problem/Motivation

Currently, Replication Filters apply only when "pushing" a workspace (i.e., when merging). It seems to me that filters would make more sense and be more useful if they applied to the opposite - on pull. It's also been suggested that they could apply to both directions... or even be configurable.

There are a lot of different terms, so to be clear:

Push:
What happens when you deploy a workspace back to its defined upstream. This can be triggered by the deploy module or by setting a Workspace's moderation state to Published. In git terminology, this is similar to `merge`.

Pull:
What happens when you click on the "Update" button on a Workspace that has an upstream target workspace defined. In git terminology, this is similar to `rebase`.

Proposed resolution

It makes more sense to me have filters apply only when pulling. That way, users could avoid pulling content that they're not interested in - e.g. comments. This becomes more important when we consider that the initial Pull operation is expensive. I would also argue that filtering on push is contrary to how we envision people using workspaces. If there is something on your workspace that you do not want pushed live, then you shouldn't be pushing that workspace.

Remaining tasks

Discuss and come to a consensus.

User interface changes

I think this will depend on what the consensus is. Either way, the "Configure replication settings" field (which allows users to select the filter) should probably be more descriptive as to what its doing and when it is applied.