[AC-1615] [GSuite] Resolve conflicts using timestamps

[hwyss-anybotics]

When we check for duplicate emails, it's entirely possible that there are valid instances of this (e.g. a user has been repeatedly created and deleted, and finally created anew).

This changeset introduces the timestamp data provided by GSuite (specifically creation and deletion date), and applies the following heuristics:

• if a user was deleted before another one with the same Email address was created, then it can be ignored, and no duplicate email error need be raised
• if multiple users with the same email address were all deleted, we can safely synchronize that deletion.
• if a user has been deleted after the creation of a user with a conflicting email address, we still raise a duplicate email error.

Type of change

• Bug fix
• New feature development
• Tech debt (refactoring, code cleanup, dependency upgrades, etc)
• Build/deploy pipeline (DevOps)
• Other

Objective

We currently cannot synchronize our Google Workspace with Bitwarden, because the duplicate detection chokes on one (or more?) users that have been repeatedly created, deleted, and recreated again.

Code changes

• src/models/userEntry.ts - add fields for creationDate and deletionDate, an accessor for whichever of these is more relevant, and a newerThan(other) method to help with the sorting of duplicate email users.
• src/services/gsuite-directory.service.ts - populate the new fields when synchronizing from Google Suite
• src/services/sync.service.ts - rework the duplicate detection heuristics.

Screenshots

Testing requirements

Before you submit

• I have checked for linting errors (npm run lint) (required)
• I have added unit tests where it makes sense to do so (encouraged but not required)
• This change requires a documentation update (notify the documentation team)
• This change has particular deployment requirements (notify the DevOps team)

[CLAassistant]

All committers have signed the CLA.

[bitwarden-bot]

Thank you for your contribution! We've added this to our internal Community PR board for review.
ID: AC-1615