fix(3127): Only run the qss log sync interval once the auth connection is properly up and running

[islathehut]

Pull Request Checklist

• I have linked this PR to a related GitHub issue.
• I have added a description of the change (and Github issue number, if any) to the root CHANGELOG.md.

(Optional) Mobile checklist

Please ensure you completed the following checks if you did any changes to the mobile package:

• I have run e2e tests for mobile
• I have updated base screenshots for visual regression tests

[islathehut]

The overview of why this works:

We were triggering the log pull interval in two places under normal circumstances:

1. immediately after starting the connection if the connection was "active" and we are a member on the chain
2. when the auth connection emits the connected event

The first trigger is what was causing issues. In this context the "active" status was based solely on whether the connection had been stopped or not. Trying to pull log entries would be impossible at this point as both quiet and qss would reject since the connection wasn't fully established.

The second trigger was firing correctly but since the interval already existed we ignored it and continued waiting for the timer to finish before starting a new attempt.

The fix here is to track the LFA connection status in more detail so we know which stage of its lifecycle its in and migrate actions like "start pulling logs from qss" on whether we have completed the identity challenge or not and only using the more vague "active" state of the connection (i.e. is the connection actively doing something) for actions such as restarting/replacing stopped connections that don't rely on the LFA lifecycle.

Something odd to note here:

I originally migrated to using a new event, connectionSecured that fired when we derived the encryption key the auth connection used since that's guaranteed to happen after the identity challenge and I was seeing two instances of the connected event being fired at two points in the LFA connection lifecycle. I migrated back because while checking the logs to provide an accurate write-up here I'm no longer seeing the duplicate events and I don't have the old logs to double check. I may have hallucinated it but if I didn't and it is intermittent we should keep it in mind in the future if the delay shows up again or any other weird behavior happens when triggered by this event.

[adrastaea]

I like the improvements to the auth conn classes status tracking, but I also think that we could have just done the simplification I describe in my QSSService comment, and removed the need for them. It's fine if the first couple sync requests fail as long as we start an interval.

I'm approving, but consider my style comment before merging please :)

[adrastaea]

The naming of this getter gets a little confusing when there's a status called QSSAuthConnStatus.ACTIVE, so intuitively it seems like this should only return true when the state is ACTIVE, not also when it is only STARTING

[islathehut]

I originally decided to rename this to running but decided to go back to active but renamed the ACTIVE status to CONNECTED which is more accurate.

[adrastaea]

It kind of seems like this was actually the issue which is that if you got the connected event from LFA, but were not a member yet, that we just wouldn't start an interval. So it would actually be circumstance 2 (referencing your comment), that was broken. Circumstance 1 would occur if you were an existing member, or if you were the creator, but 2 would be broken if you were joining for the first time.

Seems like we could just cut out any check on being a member or not, and just start the log pull interval as soon as we get the connected event. Basically, just remove lines 616:619 and 599:606. That would be functionally equivalent to these changes without any of the updated state tracking.

[islathehut]

The issue was that we were optimistically starting the interval when the connection began but at that point QSS hadn't confirmed that the user was actually a member of the community. The interval was reliably starting but the first log pull didn't happen until it hit that 30 second threshold to rerun the interval logic. Within that time the connection was able to work since the auth connection was stable and QSS could confirm membership. This was happening with new users and with existing users.

[islathehut]

This was primarily because the active property of the auth connection would be true as long as the connection was doing something and was more of an "in-use" check. Since we called the interval at both the connected event and on creation if active was true we would call the interval twice but the first time (when active was true) we had an working ws connection with QSS but no record of authentication yet since the LFA handshake was in-progress.