Make API requests through nym-http-api-client

[jmwample]

This change is intended to reduce (ideally to 0) the number of places that we are accessing the Nym API without using the nym-http-api-client.

There were only a handful of places that this was not already the case. While there is likely a more efficient refactor that could be done to better organize the API accesses and the resources that we build out of those accesses, that is not in the scope of this PR.

There is some slight awkwardness around the async / sync function calls here. I tried to keep the existing function signatures as they were which in some places meant using a block_on to call an async fn in a sync context.

---

This change is 

[octol]

Great to see this being tidied up! Well done

Just FYI, this is the nym-vpn-api, not to be confused with the nym-api which, while it has a similar name, has a wildly different purpose

Reviewable status: 0 of 15 files reviewed, 5 unresolved discussions (waiting on @jmwample)

---

nym-vpn-core/crates/nym-vpn-network-config/src/envs.rs line 16 at r1 (raw file):

use super::{MAX_FILE_AGE, NETWORKS_SUBDIR};

// TODO: integrate with nym-vpn-api-client

Maybe this comment is now out of date?

---

nym-vpn-core/crates/nym-vpn-api-client/src/error.rs line 119 at r1 (raw file):

    #[error("failed to get vpn network Details")]
    FailedToGetVPNNetworkDetails(#[source] HttpClientError<UnexpectedError>),

Please use FailedToGetVpnNetworkDetails capitalization for consistency and readability

---

nym-vpn-core/crates/nym-vpn-api-client/src/client.rs line 874 at r1 (raw file):

// Bootstrapping Environments and Network Discovery
impl VpnApiClient {

Since the bootstrap functions are intended to be used in quite separate contexts to the other functions, I wonder if it should be separate? Something like a

struct BootstrapVpnApiClient {
    inner: VpnApiClient,
}

since it's not a general purpose vpn-api-client? Then I think it will be more clear in the caller context what is going on, and it will not be possible to start calling the other methods.

And we can move it to a separate mod and file

---

nym-vpn-core/crates/nym-vpn-api-client/src/client.rs line 878 at r1 (raw file):

    /// allowing more refined URL usage.
    // hard coded for now.
    const WELLKNOWN_URL: &str = "https://nymvpn.com/api";

This url is part of the at-build-time generated default implementation of Discovery, I wonder if it makes sense to refer to that one instead of duplicating it? I'm thinking you could pass it down the callstack?

---

nym-vpn-core/crates/nym-vpn-api-client/src/client.rs line 932 at r1 (raw file):

    pub async fn get_nym_vpn_network_details(&self) -> Result<NymWellknownDiscoveryItem> {
        tracing::debug!("Fetching nym vpn network details");

Just a fyi, likely better to attach a tracing::instrument to the function instead.
But I think this code was just moved as-is so I don't think it's required in this PR

---

nym-vpn-core/crates/nym-vpn-network-config/src/discovery.rs line 55 at r1 (raw file):

    pub fn fetch(network_name: &str) -> anyhow::Result<Self> {
        let client = VpnApiClient::well_known()?;

You can pass in the bootstrap URL here. The one that is generated as part of the Default impl