Unify TorConnect UI usage

Merge Info

• Related Issues

  • #41608 (closed)

• Backport Timeline

  • Immediate - patchsets for critical bug fixes or other major blocker (e.g. fixes for a 0-day exploit) OR patchsets with trivial changes which do not need testing (e.g. fixes for typos or fixes easily verified in a local developer build)
  • Next Minor Stable Release - patchset that needs to be verified in nightly before backport
  • Eventually - patchset that needs to be verified in alpha before backport
  • No Backport - patchset for the next major stable

• Upstream Merging

  • No merge.

• Issue Tracking

  • Link resolved issues with appropriate Release Prep issue for changelog generation

Change Description

Preparation for #41608 (closed)

This just some small tidy ups to the usage of TorConnect so that different UI components use the same methods and operate the same.

In particular:

• TorConnect.hasBootstrapEverFailed renamed to TorConnect.potentiallyBlocked so that we could possibly add some nuance to this state.
• TorConnect.hasEverFailed added as a catch-all failure flag. E.g. it also captures whether we have had a failure to not being connected to the internet.
• Dropping TorMonitorService.bootstrapErrorOccurred to instead use TorConnect.potentiallyBlocked.
• Using TorConnect.enabled instead of TorMonitorService.ownsTorDaemon.
• Using TorConnect.canBeginBootstrap and TorConnect.canBeginAutoBootstrap to determine whether to show the "Connect/Try Again" and "Choose a bridge for me..." buttons in "about:preferences#connection".
• Only start Bootstrapping with the "Try Again" button in "about:preferences#connection" if TorConnect.potentiallyBlocked is not set. Before this would triggers regular Bootstrapping, rather than AutoBootstrapping, which wasn't very useful and "about:torconnect" would incorrectly show "Trying a Bridge".
• Clicking the "Choose a bridge for me..." button now also switches to "about:torconnect".