Shouldn't we pass identityAuthResult.userID here to avoid any possible race conditions? And use fullBackupSupportEnabled instead of hook

In theory, passing identityAuthResult.userID here to avoid a race condition might be reasonable too, but since it is native specific, we'll base this on whether this is staff release

Unfortunately, that's not great and different from JS; we don't check the userID here, which means if a staff user tries to restore on a non-staff release app, it will fail.

We should either:

1. Split the definition, to on web we based on userID, on native only on staffRelease flag
2. Inform all staff users not to use non-staff release apps on native
3. Try to get rid of the C++ implementation of this flag. In captureBackupLogForLastOperation, we can check if the Rust backup thread is started, but doing this while creating a DB instance seems complicated

This is all caused by the fact that we've never prioritized ENG-10124

For option 1, we should also inform staff users that it won't work on non-staff release's device but shouldn't be a problem, because in this case app should work (without backup but not crash)

Good idea

Actually, using identityAuthResult is better; the less hooks, the better. Thanks!

As we discussed offline, this isn't that simple, and basing this on userID everywhere requires significant changes.
Fortunately, the C++ flag only gates the logs generation and compaction/logs upload - so it's specific to native and primary device. So we don't have to worry about web. Moreover, this C++ code is gated by JS BackupHandler which has correct gate based on userID.

I think it's not worth doing anything beyond informing that on non-staff release, logs/compactions won't be generated/uploaded. The problem disappears when we launch backup to public.