Check for subscriber calendar ownership when creating calendar records

[davinotdavid]

Description of the Change

Before, we were only creating calendar records if it hasn't been created yet, otherwise we were just updating. The lookup for whether or not it had been created was only based on the calendar_url itself.

Bug flow:

• Subscriber A connects Google Account A (google_url_a) with X, Y and Z calendars. This succeeds since it is the first time that google_url_a is used.
• Subscriber B also connects Google Account A (google_url_a), except that when we try to create the calendar records, we see that google_url_a is already there, therefore we attempt to update the calendars instead.

Now we are also checking for calendar ownership so that calendar records are created if they don't exist for a subscriber (even if the calendar_url is the same).

How to test

Prerequisites:

• If you are using AUTH_SCHEME=oidc you will need access to whichever Keycloak instance you are connecting to and have two users set up there!
• Easier to do if you remove all containers and volumes with a docker compose down -v and docker compose up -d --build
• Have a Google Account with calendars available

1. Go through the FTUE with the first user (A) and connect a google account
2. Logout
3. Go through the FTUE with the second user (B) and connect the same google account used in step 1
4. Check that you can still connect and there are calendars available

Benefits

• Calendar records will be created for each subscriber based on their ownership (same Google Calendar in different subscribers will each have their own calendar since they have different

Applicable Issues

Fixes #1458

[devmount]

Thanks Davi! Also for providing tests!! Just one comment below. I can't really test this locally since I don't have access to a keycloak instance

[davinotdavid]

@devmount thanks for the review! You can also run with AUTH_SCHEME=password as well in that case as it shouldn't change the fix

[devmount]

@davinotdavid Oh you're right, haha! I can test this tomorrow if you want, although I think this PR is ready to be merged in. It's not that big of a change.

[davinotdavid]

@devmount All good! It is a small change indeed so I will merge this for now. Thanks!