Fix zulip group zulip-id availability check

[jieyouxu]

The previous validate_zulip_group_ids check logic is not quite correct in two ways:

1. The previous logic was too strict, in that it does not properly account for the case where a team member may not be included in any team-associated zulip user groups (such as via the excluded-people mechanism).
2. The previous logic I think was also too loose, in that it is possible to attach additional extra people via extra-people. It is possible to include a person whose people/ entry contain only a github handle, and not also a zulip id.

Example

Consider the cloud-compute marker-team:

name = "cloud-compute"
kind = "marker-team"

[people]
leads = []
members = [
   "have_zulip_id",
   "no_zulip_id",
]

[[zulip-groups]]
name = "cloud-compute"
extra-people = [
   "extra_no_zulip_id",
]
excluded-people = [
   "no_zulip_id",
]

The "all zulip group members must have a zulip-id" validation should fail, but not against no_zulip_id, because that member is not part of any zulip groups associated with cloud-compute team. It should error on extra_no_zulip_id however.

Review remarks

Let me know if these validations have any tests... I can't figure out if the static-api tests are intended for this purpose, I don't think so. I tested these two cases manually, and the revised logic seems to behave as I would expect it to.

[jieyouxu]

Context: the zulip groups I was trying to create for infra announcement channel.

cf. #t-infra > Communication method for dev desktops @ 💬

[github-actions]

Dry-run check results

[WARN  sync_team] sync-team is running in dry mode, no changes will be applied.
[INFO  sync_team] synchronizing github
[INFO  sync_team] 💻 Team Diffs:
    📝 Editing team 'rust-lang/all':
      Adding member 'graciegregory' with member role
    📝 Editing team 'rust-lang/community-survey':
      Adding member 'graciegregory' with member role
    📝 Editing team 'rust-lang/wg-triage':
      Adding member 'edmilsonefs' with member role

[marcoieni]

Does the old logic require that all members of teams have a zulip id? If yes, are we loosing this property with this change?

[jieyouxu]

Does the old logic require that all members of teams have a zulip id? If yes, are we loosing this property with this change?

As far as I can discern, this "obligation" is induced by being part of a [[zulip-group]] or a [[zulip-stream]], but is not directly induced by being part of a project team / marker-team. Many project teams do have an explicit [[zulip-group]] and a private [[zulip-stream]] which by default would include all team members, thereby transitively introducing the "all team members must have zulip ID" requirement (unless opt-out).

Manual testing

Manual testing so you can try to reproduce my testing if you wish:

Being part of a team does not automatically require the member to have a zulip ID

Using the compiler team teams/compiler.toml as an example, with 2 synthetic people:

1. Has zulip id: people/have_zulip_id.toml

   name = 'Have Zulip ID'
   github = 'have_zulip_id'
   github-id = 123456
   email = '[email protected]'
   zulip-id = 12345

2. No zulip id: people/no_zulip.toml

   name = 'No Zulip ID'
   github = 'no_zulip_id'
   github-id = 123456
   email = '[email protected]'

I commented out the 2 compiler zulip groups and the zulip-stream entry:

#[[zulip-groups]]
#name = "T-compiler"
#
#[[zulip-groups]]
#name = "T-compiler/meeting"
#include-team-members = false
#extra-people = [
#    "davidtwco",
#    "wesleywiser",
#    "apiraino",
#    "bjorn3",
#    "SparrowLii",
#    "estebank",
#    "BoxyUwU",
#    "jieyouxu",
#    "jswrenn",
#    "tmiasko"
#]
#
#[[zulip-streams]]
#name = "t-compiler/contrib-private"

And added no_zulip_id and have_zulip_id to the compiler members.

cargo run check passes both:

1. with the commit in this PR, and
2. with the commit in this PR reverted.

With the commit in this PR, if I uncomment (i.e. re-enable) the T-compiler zulip-group,

[ERROR rust_team::validate] validation error: person `no_zulip_id` in 'compiler' is a member of a Zulip user group 'T-compiler' but has no Zulip id

And if I uncomment (i.e. re-enable) the t-compiler/contrib-private zulip stream,

validation error: person `no_zulip_id` in 'compiler' is a member of a Zulip stream but has no Zulip id
[ERROR rust_team] 1 validation errors found

(The zulip stream check is not affected by this PR AFAICT.)

Don't require zulip-id for member not in any of the zulip streams

To compare the effect before/after this change, re-enable the T-compiler zulip-group. Since there is no opt-out, cargo run check will both fail with

(before)

[ERROR rust_team::validate] validation error: person `no_zulip_id` in 'compiler' is a member of a Zulip user group but has no Zulip id

(after)

[ERROR rust_team::validate] validation error: person `no_zulip_id` in 'compiler' is a member of a Zulip user group 'T-compiler' but has no Zulip id

respectively. Now modify the T-compiler zulip-group to

[[zulip-groups]]
name = "T-compiler"
excluded-people = [
    "no_zulip_id",
]

(before)

[ERROR rust_team::validate] validation error: person `no_zulip_id` in 'compiler' is a member of a Zulip user group but has no Zulip id

And cargo run check passes after, which is the goal of this PR. Re-enabling the zulip-stream (for the private channel) will still fail because no_zulip_id, well, has no zulip-id.

To check that this "don't require zulip-id" effect correctly respects all potential zulip-groups that the member might be part of, a smoke test is the following:

You can comment out all zulip-groups and zulip-stream on compiler which has no_zulip_id as a team member, but then add no_zulip_id to teams/libs.toml which has the T-libs zulip group, and you should still observe a failure with

[ERROR rust_team::validate] validation error: person `no_zulip_id` in 'libs' is a member of a Zulip user group 'T-libs' but has no Zulip id

[Kobzol]

This looks good.

[marcoieni]

sorry it took so long!

[jieyouxu]

sorry it took so long!

No worries, the announcement channel is blocked on the T-all situation anyway :D