Updates teosd.service

[sr-gi]

Updates teosd.service to add tor.service to Wants=, so it waits for tor to be initialized if it has to.

Will keep this open for now though, more modifications may pop up while testing v0.2.0-rc1.

[sr-gi]

I've added a static wait before starting teosd.service to give time to bitcoind.service to start. This is not ideal, but would do the trick for now. I see two alternative solutions to this:

• Properly set-up the service to retry after failing. I've tried this with no luck, even though the config seems to be in place for it
• Make the code retry the bitcoind connection for a while before failing. This look like (using retry):

let rpc_credentials = base64::encode(&format!("{}:{}", rpc_user, rpc_password));
let bitcoind_rpc_client =
    retry_with_index(Exponential::from_millis(1000).map(jitter).take(5), |i| {
        RpcClient::new(
            &rpc_credentials,
            HttpEndpoint::for_host(host.to_owned()).with_port(port),
        )
        .map_err(|e| {
            let mut message = format!("Cannot connect to bitcoind: {e}");
            if i < 5 {
                message = format!("{message}. Retrying shortly")
            } else {
                message = format!("{message}. Giving up")
            }
            log::error!("{message}");
            e
        })
    })
    .map_err(|e| e.error)?; 

However, this only covers the connection itself, after establishing it bitcoind may be busy (loading the wallets, indexing, etc) so the same has to be applied to :

// Test that bitcoind is reachable.
let btc_network = client.get_chain().await?;

However, this is an async function, meaning it may need even another additional dependency.

I'd lean towards fixing this at the service level

[sr-gi]

Fixed this via https://github.com/talaia-labs/rust-teos/issues/187#issuecomment-1419177129