Similar to the Rust SDK's `Provider::connect`:

/// Connects to an existing node at the given address.
    pub async fn connect(url: impl AsRef<str>) -> Result<Provider> {
        let client = FuelClient::new(url).map_err(|err| error!(InfrastructureError, "{err}"))?;
        let consensus_parameters = client.chain_info().await?.consensus_parameters.into();
        Ok(Provider::new(client, consensus_parameters))
    }

In the TS SDK, we could have:

// new API
const provider = await Provider.connect('https://node.url');

// old API
const provider = new Provider('https://node.url')

### Motivation behind this API change
Making the initialization of the provider asynchronous will let us internally fetch consensus parameters from the chain and cache them on our provider object for later use.

This means that all of our internal logic related to contract calls can stay synchronous as it is with minimal modifications, and just consume these cached consensus parameters from the provider object whenever needed.

Please also have a look at [my draft PR](https://github.com/FuelLabs/fuels-ts/pull/1173) that attempts to decouple calculating the script data offset from the initialization of function calls. The solution in that PR fetches these consensus parameters on *each* contract call which can make contract calls, especially multicalls significantly slower. The solution in that PR also is *very* hacky and we have not been able to figure out a way to make it work for our `ScriptInvocationScope`s yet.

Please correct me if I am wrong - but I think the consensus parameters of the chain should not change often. Still, if the user wants to invalidate the cache and wants the provider to use the latest consensus parameters, we can expose a method called `invalidateConsensusParamsCache` from the `Provider` class that lets them do that explicitly.