Rebase before landing

It's great to see these bindings! At some point, we should delete NullableString and NullableInt.

rebase before landing

rebase before landing

address comments + rebase before landing

No longer needed. Included in prior diff

Add option for user created vpc to avoid migration of prod aws rds instance to new vpc

Looks good!

Should I make a new release of @commapp/sqlcipher-amalgamation now? We should do that before landing, so we don't need to commit the patch

Requesting changes for ESLint

I updated communitiesToAutoJoin into an object so that when we call setCommunitiesToAutoJoin inside of the JoinHandler component, we would not need to use the .find() method to locate the correct community to update in communitiesToAutoJoin. I thought this would be a bit more performant

rebase before landing

Address Varun's and Will's feedbacks

Remove manual changes in XCode. I had to rever the changes in native/ios/Comm.xcodeproj/project.pbxproj for all of them to disappear.
I ran yarn cleaninstall and install pods and checked that removing and reinstalling the iOS app still doesn't throw

Don't call determineThreadAncestry twice

In D12686#359268, @will wrote:

@kamil does anything need to be done to remove redux persist integrityStore data besides adding to the persistBlacklist? On initial startup, I get a hydrated keys not expected integrityStore which doesn't appear on subsequent app opens in debug iOS Simulator

This function is supposed to be used exclusively with thick threads.

rebase before landing

It's not clear why you turned this into an object. You don't seem to be using the keys below in joinHandlers, and that seems to be the only place you communitiesToAutoJoin. Why did you update this to an object?

@will mentioned a concern I had raised in a 1:1 here. Not sure if we want to address that here, but broadly I'm worried that the health check might not work if we're doing it after bringing the load balancer publicly online with only a single node (the primary) accessible

rebase before landing

rebase before landing

I'd like to avoid querying determineThreadAncestry twice

Please re-request review if either of the following is true:

Let's do it tomorrow as you suggested

If you could remind me to make sure I set db.m6g.large when we set up my keyserver, that would be great!

Great work!!

Just two questions:

Also, there appear to be ESLint issues here that would need to be resolved prior to landing

Gonna leave this one for @marcin to confirm: