The plan for 2FA enforcement of global groups is that both local and global groups are configured using the same config variable, $wgRestrictedGroups.

The goal of that approach is to:

1. reuse as much code as possible,
2. ensure that pairs of global and local groups, which are conceptually the same, such as stewards, get consistent treatment, and
3. minimize chances for site admin overlooking the need for duplicating configuration (e.g., it's easy to overlook a need to specify restrictions for local stewards on WMF).

However, there are still cases like AbuseFilter helpers, where we'd like to enforce 2FA only from the global group, and not from local groups of the same name.

Idea

Add additional parameter to the $wgRestrictedGroups configurations, as below:

$wgRestrictedGroups['abusefilter-helper'] = [
    'memberConditions' => [ /* ... */ ],
    'scope' => [ 'centralauth' ],
];

Where scope would list all scopes that the restriction relates to. For local groups, it would be 'local', for other types – an extension-defined string.

The approach doesn't allow for different restrictions for different scopes, as for now there's no need to support that. If it changes, the values of $wgRestrictedGroups can be changed to be either descriptors (like now) or arrays of descriptors, where the first relevant descriptor will be used. Implementing that is out of the scope of this task – and not needed as of now.

Acceptance criteria

• If restricted group doesn't specify scope, the restrictions are considered relevant for any scope.
• If restricted group specifies a list of scopes, it's relevant for any of them, but irrelevant for any other scope.
• RestrictedUserGroupCheckerFactory creates checkers that only consider restrictions relevant for the requested scope.
• If no scope is explicitly requested, RestrictedUserGroupCheckerFactory creates by default checkers bound to the local scope.