Introduce CreateBare, deprecated CreateInherent

[gui1117]

Rename CreateInherent to CreateBare, add method create_bare and deprecate create_inherent.

Both unsigned transaction and inherent use the extrinsic type Bare.
Before this PR CreateInherent trait was use to generate unsigned transaction, now unsigned transaction can be generated using a proper trait CreateBare.

How to upgrade:

• Change usage of CreateInherent to CreateBare and create_inherent to create_bare.
• Implement CreateBare for the runtime, the method create_bare is usually implemented using Extrinsic::new_bare.

[bkchr]

The naming is still just wrong and trying to fix this via docs is not making it better. As I already said in the original pr, the name of the trait is wrong.

I would propose we introduce a new CreateBare with proper docs and tag this trait deprecated.

[gui1117]

I updated the PR: deprecate CreateInherent, introduce CreateBare and replace all usage in polkadot-sdk.

It is a breaking change so I am not sure I can backport anything to 2412, but I will backport it to 2503.

I acknowledge my mistake in transaction extension review, also overall I underestimated the stability and the pace of new feature in polkadot-sdk in 2024.

As a side note I think offchain traits could be improved as well:

• we could remove LocalCall everywhere, people can bound RuntimeCall: From<Call> in their config
• CreateTransactionBase could simply bound frame_system::Config as supertrait instead of having a duplicated associated type RuntimeCall that bring name conflict. (We do bound Config as supertrait for SigningTypes).
  But better not to break them.

[georgepisaltu]

I agree with the offchain trait refactor, but it's probably best to do it after phase 2 of Extrinsic Horizon is done.

[bkchr]

If you change this, it basically means that people may have CreateInherent implemented, but it will not be used by anything.

[bkchr]

Basically also resulting in compile errors.

[gui1117]

If we do this, runtime will have to implement CreateInherent with the intention of creating a bare extrinsic.

It is ok to me, and the least breaking change, but it keeps the faulty trait usage: CreateInherent, I will also add in the doc of CreateInherent the intention.

[gui1117]

I updated the code:

• CreateInherent has a new method create_bare with default implementation. User can override it to specify the behavior. (not ideal but not a breaking change.)
• CreateBare is introduced, automatically implemented for CreateInherent using CreateInherent::create_bare.
• CreateBare is used instead of CreateInherent for SendUnsignedTransaction and it implementation for Signer.
• pallets such as beefy are not using CreateBare in their trait bound to avoid any breaking change.
• User are expected to implement CreateInherent for their runtime in order to keep pallet's usage.
• User are expected to use CreateBare in their pallet, the idiomatic trait to create a bare extrinsic.

Possible alternative design: slightly more breaking, but provides a path forward:

• I considered deprecated CreateInherent and use CreateBare in polkadot-sdk pallets. That would be a breaking change: e.g. if a pallets bounds beefy config and use T::create_inherent method then their code then it won't compile. They have to use create_bare and import CreateBase trait in scope. (note: we could introduce CreateBare::create_inherent so that rustc give some hint to import the trait in scope.)

[georgepisaltu]

I think it's ok as it is right now, fixes the name and helps the dev a bit with the default impl.

[gui1117]

/cmd fmt

[gui1117]

It doesn't work either, because CreateBare takes a generic so we can't implement it directly when it is derived automatically for CreateInherent:

error[E0119]: conflicting implementations of trait `frame_system::offchain::CreateBare<_>` for type `mock::Test`
  --> substrate/frame/sassafras/src/mock.rs:59:1
   |
59 | / impl<C> frame_system::offchain::CreateBare<C> for Test
60 | | where
61 | |     RuntimeCall: From<C>,
   | |_________________________^
   |
   = note: conflicting implementation in crate `frame_system`:
           - impl<LocalCall, T> frame_system::offchain::CreateBare<LocalCall> for T
             where T: CreateInherent<LocalCall>;
   = note: downstream crates may implement trait `frame_system::offchain::CreateInherent<_>` for type `mock::Test`

For more information about this error, try `rustc --explain E0119`.
error: could not compile `pallet-sassafras` (lib test) due to 1 previous error

So instead I just renamed the trait CreateInherent to CreateBare, deprecated the method create_inherent and added the method create_bare, people updating their code will have a compile error saying create_bare is not implemented, I think it is fine because it is very easy to implement. Other than that there is no breaking change.

The deprecation of a reexport doesn't work in rust, but the doc show the rename so if people use an IDE they will see the trait is renamed.

[gui1117]

Considering approvals here for the PR when it was in a different state, I am not sure I should consider this PR approved.

But IMO it looks good.

[gui1117]

Having CreateBare as a trait automatically implemented for implementations CreateInherent is not doable because the trait is generic and it will fail with:

error[E0119]: conflicting implementations of trait `Bare<_>` for type `Runtime`
 --> src/lib.rs:3:1
  |
3 | impl<Call> major::Bare<Call> for Runtime {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `major`:
          - impl<Call, T> Bare<Call> for T
            where T: Inherent<Call>;
  = note: downstream crates may implement trait `major::Inherent<_>` for type `Runtime`

For more information about this error, try `rustc --explain E0119`.

Having CreateInherent automatically implemented for CreateBare is doable but it is a breaking change, user will have to remove their implementation of CreateInherent and instead implement CreateBare.

In this PR, I choose a rename of the trait, I know renames are not very good but the documentation CreateInherent will show that it is renamed to CreateBare and "deprecated".

Another solution would simply to mark the trait as deprecated and create a new trait, and update all our usage for the new trait CreateBare. This will give a good deprecated warning message but also some compile error because CreateBare is not implemented.

If you have some opinion @bkchr

[gui1117]

@bkchr because you approve a different version that I had to change because it didn't work at the end.

This final version is:
A new trait CreateBare with 2 methods create_bare and deprecated create_inherent that default implementation is create_bare.
CreateInherent is rewrote as a type alias to CreateBare with a documentation saying it is deprecated.

User using CreateInherent will just have a warning create_inherent is deprecated in favor of create_bare.
Implementer of CreateInherent will have a compile error saying create_bare is not implemented.

I think it is good.