Rebase

In D11177#323033, @atul wrote:

Looks good, just want to make sure that this won't break any older clients? I see the following in Test Plan:

Run an older native client and check if it works with new keyserver.

so I'm assuming this table and functionality was never used?

Tested native migration and deleted web migration - we aren't persisting actualizedCalendarQuery on web
and we don't need to migrate it - default state contains a new value.

Fix top-level default keyserver info - the app was crashing because config isn't registered when executing
top-level

Update native state type
Use defaultCalendarQuery function in the default keyserver store
Handle actualizedCalendarQuery from an initial state in the reducer

In D11099#321944, @atul wrote:

In D11099#320649, @tomek wrote:

What is the downside of making this diff a draft instead of marking its title with a label?

Would that still make the diff viewable to reviewers?

Fix tests by introducing a jest mock

I think that keeping the solution as symmetrical as possible is a good idea. In this case, we should probably add it to IdentityServiceClient. If we can expose it also on native, it would be even better. And we should determine why there's an asymmetry of how the keys are uploaded and ideally make it consistent.

Move map to a context

Rebase

What is the downside of making this diff a draft instead of marking its title with a label?

Could you link to the code that you're reintroducing?

In D11088#320294, @ashoat wrote:

The synchronizeInviteLinksWithBlobs.js filename does not follow conventions in our codebase. We should maintain consistent file naming conventions. @tomek, can you do an audit of the invite links code to make sure we match file naming conventions with the rest of the codebase? Would be great if you could create a task to track

It wasn't intentional. Thanks for fixing it!