validate orbot availability before initiating recoverbull connection

[basantagoswami]

Fixes #1691

Before: Recoverbull checked the useTorProxy user setting to decide whether to use Orbot or start the embedded client. That worked only when the setting was enabled by user. If it was not enabled by the user, the app tried to start the embedded client and Orbot would block Tor over Tor connections

This PR fixes that issue, by checking if Orbot is actually running on the default port (9050)

This PR doesn't fix the case where Orbot is running in some custom port, and the user has not enabled the setting to use external Tor proxy, which is unlikely

Future work could be to somehow detect these Tor over Tor errors (if Orbot returns them), and display that to users

[kumulynja]

Good catch and good fix! Tested with Orbot running without setting an external proxy from develop branch and indeed got an error, then tested with this branch with Orbot and RecoverBull worked 👍

Just some structure and naming conventions that I would like to see changed, but that's a more general problem unrelated to this issue, so will be tackled in other PR's.
Just for sharing, this is how I think all Tor related things should be structured:

• Only thing in core: Some factory class to get a http client from a Tor proxy port, like the function that is currently in the tor_datasource in core. This can be used then by any adapter in any feature that needs tor and either the embedded tor client port or the external configured proxy port can be passed to it when needed.
• Just one Tor feature with:
  • Embedded Tor client wrapper that could be started and where the port can be returned from.
  • Management of the Tor settings like enabling/disabling the embedded client, the external proxy port etc.
  • Facade api to:
    • Get port if Tor is already available (either from running embedded client port or external proxy port). Can return null if none is available
    • Enable/disable embedded client from other features if returned port above is null.
    • Maybe a third function to get the Tor status with some more details and a real check if the connection is working, which can be useful for the Status feature.
• For the specific problem of the PR, the Tor settings feature should also add a Port (abstract class) to check for any external running Tor clients even if they are not set by the user. This can then be used in the usecases before starting the embedded client or saving the external proxy port to settings. It can be reused to both check any predefined default ports like 9050 before starting the embedded client, as well as to check the external port set by the user before saving it.
• Other features that need tor, like Recoverbull feature can then just get the proxy port to use from the Tor feature (so they all depend on Tor settings) and pass that port to whatever has a socks5 param, or use the Http client factory of core to pass the port and use that client for their calls. This would be done in the specific adapters of those features, like in a RecoverBullGatewayPort adapter for example. (It’s perfectly fine to use a facade of a feature it depends on in its own adapters, since it’s just another dependency from that features’ point of view)

[i5hi]

New issue with architectural fixes suggested by @kumulynja
#1839