VC/Zoom: Resolve registrant emails via a bulk user directory

[moliholy]

When automatic registration is enabled on an event, resolving each registrant's Zoom-account email used to trigger its own get_user call. On an event with hundreds or thousands of registrants that meant one Zoom API call per person on every registration and approval, and once per participant on check-in.

This PR removes that per-registrant call on both fronts:

• Bulk sync paths (pushing registrants when the setting is turned on, and syncing on registration or approval) fetch the account user directory once through List Users and resolve everyone against it locally. The directory is fetched lazily and then reused from the shared cache for a few minutes, so most requests skip the account walk entirely. Single-user paths (the meeting host, a registrant's personalized join link) keep the cheaper per-user lookup.
• Participant check-in is resolved with a single indexed database lookup. Zoom already gives us the participant's exact email, so the matching registration is found directly (by registration email, account email, or identity, depending on the configured user lookup mode) with no Zoom call, keeping the webhook well within Zoom's response window.

On those same bulk paths, the check that decides whether a registrant is already covered by another active registration also used to run one database query per registrant. It now builds the set of active registrations for the event once per sync and reuses it, so a sync of thousands of registrants issues a single query instead of one per person.

It also fixes a related correctness issue on the sync path: a registration created while still awaiting moderation is no longer cancelled in Zoom. Only completed registrations are ever added to a meeting, so a pending one has nothing to cancel; the queued sync is now a no-op for it instead of issuing a cancellation that reached the registrant as a spurious cancellation notice.

Outgoing Zoom API requests are also logged at debug level, so the exact sequence of calls a registration or approval triggers can be traced when diagnosing a slow or misbehaving event.

Note: the directory lookup depends on the user:read:list_users:admin scope.

[moliholy]

@ThiefMaster this is a bug currently, as with thousands of users the request returns a 504 and:

• Leaves an inconsistent state: not all users are registered on Zoom, but a subset of them.
• Both auto-registration and check-in flags are not saved, as such operation is done after all participants are registered, but the operation gets aborted.

Regardless: it is very inefficient to perform O(n) queries to Zoom just get the emails.

[moliholy]

I confirm the optimizations are working fine after the fix was deployed in a customer's infra a few days ago.

[ThiefMaster]

I think doing this unconditionally is extremely inefficient for the - often much more common - case of having few registrations and many Zoom users.

It would be good to have a setting for a threshold and/or cache the list of Zoom users in a more persistent way (for a few hours) and fall back to the individual lookup only for users that aren't in the cache.

[moliholy]

I added a hardcoded limit of 25 users to trigger the fetch in b55f974. I find a plugin setting too technical for users, as they don't really have to know about this issue nor I think can really evaluate the consequences.

In any case happy to change it if you think otherwise.