Fix error handling and capturing

Rebase

Modify function signature

Wondering about the consequences of this rename. It feels like it could break the compatibility of our reports - an older report could contain one of registerActionTypes actions that can't be recognized by the more recent code.

Wondering about the impact on the keyserver - if all the clients use HTTP, it might result in a lot of open HTTP connections. Also, from the client's point of view, it might result in a lot of open connections (probably more than a browser allows). So I think we should move only some requests to HTTP, but I might be wrong.

Debugged it a bit and figured out what's going on. It seems like the Identity service doesn't recognize ashoatKeyserverID to be an ID of Ashoat's user. Instead, in identity-users table there's an entry for the user whose value is some UUID (different for staging and prod). After using the ID from the table, this code works correctly.

In D10403#301009, @varun wrote:

what's not working?

I would guess that failing to process the reports also shouldn't cause clearing the db - if we fail the operation, we won't save a report, and by clearing the db we're making things a little worse.

This diff still has an issue: when calling a new keyserver, it returns sessionChange which causes setNewSession to be dispatched - this results in the keyserver being added to a store in an incorrect way and breaks more things down the line.

In D10157#299660, @inka wrote:

I wanted to move reducing loading statuses to web and native reducers altogether, but I couldn't overcome a flow problem:
I don't want to copy the reduceLoadingStatuses reducer to web and native, so it is located in lib. It takes an action: BaseAction. I was unable to type it in a way that wouldn't cause errors. If I make the action be an inexact BaseAction, like flow docs suggest: action: {...BaseAction, ...}, then I get errors about read-only properties, as the action I'm passing into the function has nested read-only fields, and the action that is being taken by the reducer was stripped of all read-only.
This works, because setNewSessionActionType, logOutActionTypes and deleteAccountActionTypes are in BaseAction
I know this is not ideal, but it fixes the issue, and is way less hacky than the previous solution.

Looks a lot cleaner!

Probably fix the override. This still requires a lot of testing and thinking about
memoization, but it isn't broken in an obvious way.

Use optional

Use the correct key in overrides. Tested it by specifying keyserver override in web link
handler.

const validateLink = useVerifyInviteLink({
  keyserverID: ashoatKeyserverID,
  keyserverURL: 'http://localhost:3000/keyserver',
});

This calls the proper endpoint, but causes some other issues - e.g. invite link
verification assumes that a user is logged in, which isn't always true when using an invite
link. Going to fix this in the next diffs.

I'm going to check the option of using MariaDB transactions to minimize the number of possible race conditions

This solution is hacky - we're discarding loading statuses of requests that will be resolved later. Instead, we should reduce loading statuses before we check invalidSessionDowngrade.

I don't think there was a good reason behind this await

Split a function into two

In D10150#295223, @ashoat wrote:

This feels pretty messy. I'm not sure what the callstack looks like, but is it possible to introduce a second function for this (with shared code factored out) instead of overloading fetchPrimaryInviteLinks to handle two different scenarios?

Rebase

Rebase

Use a param object instead of two args for hash and holder to avoid the confusion between them

Accepting without review. What procedure did you use to rename all the types?