bug: cannot fetch mint transactions

[segfault-magnet]

closes #1199

Mint transactions can now be fetched through the Provider. Implemented what made sense for Mint, left the rest as unimplemented!. Without some hefty redesign don't see what other option is there but to violate the LSP (L for Liskov).

Decided to wrap Mint, so that users may extract the id, outputs, etc, without having to know about the various traits from fuel.

Checklist

• I have linked to any relevant issues.
• I have updated the documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary labels.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[Voxelot]

Maybe it'd be better to just return an error instead of panicking? Imo we shouldn't have any public apis exposed to users that allow them to cause a panic.

[segfault-magnet]

I started a discussion about not implementing this trait at all. If that for some reason isn't accepted, I'll change the trait so that methods that would have passed normally on a Script or Create will fail in the case of a Mint transaction.

[MujkicA]

Does Mint have to implement Transaction? We use the trait as a common interface for Create and Script when submitting them to the provider and AFAIK submitting Mint currently makes no sense.
IMO it's better to not implement Transaction here since it will also guard against passing the tx where it doesn't belong.

On the other hand a transaction that is not Transaction could be confusing. Maybe renaming the trait to something like SubmittableTransaction would make sense.

[Voxelot]

In the VM we use a trait called ExecutableTransaction so that it only accepts create or script txs

[segfault-magnet]

Does Mint have to implement Transaction? We use the trait as a common interface for Create and Script when submitting them to the provider and AFAIK submitting Mint currently makes no sense.

If you take a closer look you'll notice that Mint doesn't implement Transaction. Rather it is the TransactionType enum that implements it. Its Transaction implementation just delegates to the underlying transaction. But how do you delegate the methods that only make sense for Create of Script to the Mint transaction? This is the breaking of the LSP I mentioned above.

You also cannot implement something like ExecutableTransaction since you'll have the same problem -- what to do with the Mint variant?

The only solution is not to implement anything for this enum and have it just be a bare enum, used so that we can return Create, Script, or Mint transactions requested by the user via the get_transactions endpoint of the Provider.

I don't see the methods of Transaction being used with a TransactionType -- I think the goal was to circumvent the issues of the trait not being object safe by using an enum and just delegating to the variants. This, as mentioned above, falls apart with the introduction of Mint.

I suggest we remove the Transaction impl from the TransactionType and have users match, extract the underlying transaction and then call whatever they like on it.

@MujkicA @Voxelot

[segfault-magnet]

Ended up removing the Transaction implementation from the TransactionType. Now it is just a simple wrapper around the three transactions.

[hal3e]

LGTM!