Replication frequently gets PRs similar to this one:

https://github.com/10gen/mongo/pull/53049

The general shape is: replication tests have filters on the commands to test. Every time a command is added or changed in such a way that it should be {in,ex}cluded from the replication tests, the PR author needs to get approval from the replication team.

These reviews are generally rubber-stamped and low-value. The replication reviewers typically do not have sufficient context on the commands being changed. The LGTM is only a formality, and meanwhile the PRs take up reviewer attention.

This could be solved using a visitor-like pattern. Replication could define an interface which determines the filter output. The code owners of the commands themselves could then own their commands' testing without having the replication team signoff as a blocker.

Ideally, this is something that could be done with a uniform solution across the codebase; however, barring such a centralized solution, I think it's valuable for the repl team to consider implementing a structure to incrementally improve the situation locally.

Acceptance criteria:

• Existing command inclusion/exclusion is preserved.
• New commands are included by default.
• Future changes to command code is not blocked on replication review.