Add sync backing logic & refactor client to be closer to AURA api

[librelois]

This PR include two distincts changes:

• A refactoring of the client part of nimbus to have an API closer to AURA, the aim is to facilitate future maintenance and migration to async backing.
• Addition of a pallet dedicated to async backing. This new pallet implements the ConsensusHook trait and stores information about the last slot (last slot number and number of blocks produced in it).
  • The new pallet introduce a trait GetAndVerifySlot to keep the pallet agnostic of the slot implementation. If your parachain don't need slots at the parachain level, you can use the RelaySlot implementation. Otherwise, use the ParaSlot implementation.

Implement the slot logic

Without parachain slot

impl async_backing::Config for Runtime {
    ...
    type GetAndVerifySlot = RelaySlot;
}

With parachain slot

struct SlotProvider;
impl Get<(Slot, SlotDuration)> for SlotProvider {
    fn get() -> (Slot, SlotDuration) {
        // Implement your logic here to get the current slot and the slot duration
    }
}

impl async_backing::Config for Runtime {
    ...
    type GetAndVerifySlot = ParaSlot<RELAY_CHAIN_SLOT_DURATION_MILLIS, SlotProvider>;
}

[Agusrodri]

The changes look great so far, awesome work @librelois! Once we have everything compiling, we should start testing how the node behaves in terms of collation before merging. I compared your changes against the polkadot-parachain ones and everything seems to be correct (and also the nimbus adaptation).

[librelois]

@Agusrodri it compiles now

[Agusrodri]

While trying to set these changes on Tanssi, I wasn't being able to compile the project. I was receiving the following error while doing cargo check --release:

error[E0433]: failed to resolve: use of undeclared crate or module `std`
  --> primitives/async-backing/src/lib.rs:26:1
   |
26 | / sp_api::decl_runtime_apis! {
27 | |     /// This runtime API is used to inform potential block authors whether they will
28 | |     /// have the right to author at a slot, assuming they have claimed the slot.
29 | |     ///
...  |
49 | |     }
50 | | }
   | |_^ use of undeclared crate or module `std`
   |
   = note: this error originates in the macro `sp_api::decl_runtime_apis` (in Nightly builds, run with -Z macro-backtrace for more info)

And also this one:

error[E0433]: failed to resolve: use of undeclared crate or module `std`
   --> primitives/nimbus-primitives/src/lib.rs:168:1
    |
168 | / sp_api::decl_runtime_apis! {
169 | |     /// The runtime api used to predict whether a Nimbus author will be eligible in the given slot
170 | |     pub trait NimbusApi {
171 | |         fn can_author(author: NimbusId, relay_parent: u32, parent_header: &Block::Header) -> bool;
172 | |     }
173 | | }
    | |_^ use of undeclared crate or module `std`
    |
    = note: this error originates in the macro `sp_api::decl_runtime_apis` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0412]: cannot find type `String` in this scope
   --> primitives/nimbus-primitives/src/lib.rs:154:2
    |
154 |     app_crypto!(sr25519, crate::NIMBUS_KEY_ID);
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
    |
    = note: this error originates in the macro `$crate::app_crypto_pair_functions_if_std` which comes from the expansion of the macro `app_crypto` (in Nightly builds, run with -Z macro-backtrace for more info)

The problems got solved by removing the default-features = false from async-backing-primitives and nimbus-primitives packages. I guess this makes sense as both of them strongly depend on std features on the client side, and I think disabling std by default was bringing issues due to that.

Given this, what I suggest is to enable std by default for these two packages, and disable std for them only inside the runtime (if needed), what do you think?

Note: the client package located in this branch also doesn't compile and throws the same errors, so I think it will be an issue if we don't handle it. Let me know your opinion :)

[librelois]

Given this, what I suggest is to enable std by default for these two packages, and disable std for them only inside the runtime (if needed), what do you think?

You should do exactly the opposite, std features should be disabled by default and explicitly enabled on the client-side, it's the way substrate work.

Note: the client located in this branch also doesn't compile and throws the same errors, so I think it will be an issue if we don't handle it. Let me know your opinion :)

The moonkit template client compile well in this CI and locally with command cargo build --release -p moonkit-template, so what do you mean?

[Agusrodri]

You should do exactly the opposite, std features should be disabled by default and explicitly enabled on the client-side, it's the way substrate work.

Yes I know that's the normal way of configuring it, but seems that's not the case for these two deps, I don't know to be honest.

Edit: Adding the std feature only to the client package works fine after running cargo clean.

The moonkit template client compile well in this CI and locally with command cargo build --release -p moonkit-template, so what do you mean?

What I mean is that the client package is not compiling separately (actually is the nimbus-consensus one), to reproduce the errors you can do cargo check --release inside client/consensus/nimbus-consensus.