Blob upload optimisations

[maschad]

Follow up optimisations for #2827

• Improve sync flow. Since #2692 contract deployment has been non blocking. The blob deployment process first deploys blocking blob txs then a non blocking create tx. We should make the whole flow non blocking. Full context here.
• Improve chunk size estimation. Based on discussions with @danielbate we determined chunk estimation can be improved. The rationale is that if we know the account's balance, the transaction limit, contract limit and maximum configurable request body size, we can determine an accurate cost before deployment, and thus reduce the need for the user provided value for chunk size tolerance.
• Blob tx retry conditions - comment

[petertonysmith94]

Wouldn't this be a breaking change?

If yes, would it be worth basing off #2827 and getting it into the release?

[danielbate]

After discussing with @danielbate on the PR

for large contract deployments, we determined it may be possible to do further chunk optimization thus reducing the need for the chunkSizeTolerance parameter. The impetus for this is due to the nature of the chunkSizeTolerance parameter being difficult to set programmatically, given it's based on network fee fluctuations.

The rationale is that if we know the account's balance, the transaction limit, contract limit and maximum configurable request body size, we can determine an accurate cost before deployment, and thus remove the need for this user provided value.

This should also improve the DX as it reduces the probability of a contract deployment failure.

This is a follow up once https://github.com/FuelLabs/fuels-ts/pull/2827 is merged.

IMO the above optimisations that @maschad mentions will definitely reduce the importance of the tolerance level. However unknowns at compile time such as the configurable graph QL body size limit means we should still keep this parameter, and this not introduce a breaking change.

[danielbate]

@maschad I'm going to transition this whole issue to blob follow ups.