Change Details

[ENG-6667 : Implement "primary" tab lock](https://linear.app/comm/issue/ENG-6667) We want to only have a singular tunnelbroker connection across all tabs on web. One way to achieve this is to use the WebLockAPI. The `useWebLock` hook exposes a nicer interface to it. It returns lock status and `releaseLock` function. When the status is equal to `'should-release'` the caller is expected to run cleanup (e.g. disconnecting from the tunnelbroker) and call `releaseLock`. Some information about the web lock api: - It allows to request a lock with a specific name - The lock can be held only "in one place"/"one call to the `request` method" across all tabs of the same origin - If we make sure to only call it once in the app, we can get the required locking behaviour between tabs - (this is assuming the `exclusive` mode, which is the default) - If the lock is already taken, the `request` call goes into a queue, and will wait until the lock is released - Request in queue can be aborted with an `AbortSignall` - Call to `request` returns a promise and expects an async callback as an argument. When it acquired the lock it calls the provided callback. The promise returned by the `request` call resolves when the the promise returned from the callback resolves. Additionally our version of flow doesn't type the `LockManager` (this was also the case for e.g. service worker and shared worker types) so I had to do it myself.

[ENG-6667 : Implement "primary" tab lock](https://linear.app/comm/issue/ENG-6667) We want to only have a singular tunnelbroker connection across all tabs on web. One way to achieve this is to use the WebLockAPI. The `useWebLock` hook exposes a nicer interface to it. It returns lock status and `releaseLock` function. When the status is equal to `'should-release'` the caller is expected to run cleanup (e.g. disconnecting from the tunnelbroker) and call `releaseLock`. Only the foreground tabs will try and acquire a lock. After a tab is backgrounded it should release the lock if it has one. Some information about the web lock api: - It allows to request a lock with a specific name - The lock can be held only "in one place"/"one call to the `request` method" across all tabs of the same origin - If we make sure to only call it once in the app, we can get the required locking behaviour between tabs - (this is assuming the `exclusive` mode, which is the default) - If the lock is already taken, the `request` call goes into a queue, and will wait until the lock is released - Request in queue can be aborted with an `AbortSignall` - Call to `request` returns a promise and expects an async callback as an argument. When it acquired the lock it calls the provided callback. The promise returned by the `request` call resolves when the the promise returned from the callback resolves. - Locks are released automatically after the tab is closed Additionally our version of flow doesn't type the `LockManager` (this was also the case for e.g. service worker and shared worker types) so I had to do it myself.

[ENG-6667 : Implement "primary" tab lock](https://linear.app/comm/issue/ENG-6667) We want to only have a singular tunnelbroker connection across all tabs on web. One way to achieve this is to use the WebLockAPI. The `useWebLock` hook exposes a nicer interface to it. It returns lock status and `releaseLock` function. When the status is equal to `'should-release'` the caller is expected to run cleanup (e.g. disconnecting from the tunnelbroker) and call `releaseLock`. Only the foreground tabs will try and acquire a lock. After a tab is backgrounded it should release the lock if it has one. Some information about the web lock api: - It allows to request a lock with a specific name - The lock can be held only "in one place"/"one call to the `request` method" across all tabs of the same origin - If we make sure to only call it once in the app, we can get the required locking behaviour between tabs - (this is assuming the `exclusive` mode, which is the default) - If the lock is already taken, the `request` call goes into a queue, and will wait until the lock is released - Request in queue can be aborted with an `AbortSignall` - Call to `request` returns a promise and expects an async callback as an argument. When it acquired the lock it calls the provided callback. The promise returned by the `request` call resolves when the the promise returned from the callback resolves. - Locks are released automatically after the tab is closed Additionally our version of flow doesn't type the `LockManager` (this was also the case for e.g. service worker and shared worker types) so I had to do it myself.