feat: Combinator Steps + Atomic

[julio4]

The idea is to be able to defines combinator step: a step that is combined out of multiple underlying steps.

I introduce a CombinatorStep that is a subtrait of Step, that takes a impl Into<Vec<Arc<StepInstance<P>>>> to allows for different syntaxic sugar later :)

Then a combinator macro is defined to encapsulate base logic of creating a combinator step by:

• defining a struct with a vector to hold step instances
• auto implementation of CombinatorStep
• implementation of an append method that push the given step in the steps vec, but with the option to provide a different name (like and with atomic, or with any etc..)
• implementation of steps() function to get a slice of the step instances

The generated struct still needs to implement manually Step. This is enforced at compile time because CombinatorStep impl requires Step impl.

Other points:

• needs to clone contexts for each sub-steps
• removed Sync bounds on some futures, that seemed unnecessary

Included as well a combinator step implementation for Atomic (related work was done in #59 but moved here)

Towards #31

[karim-agha]

None of those are strong opinions, just discussion starters.

[karim-agha]

I'd suggest that we tweak the DevEx here a little bit and enable the following syntax:

let pipeline = Pipeline::default()
  .with_prologue(All((Step1, Step2, Step3))
  .step(Step4)
  .with_epilogue(Any((Step5, Step6)));

This is how this syntax is implemented for constructing pipelines:

rblib/src/pipelines/mod.rs

Lines 226 to 269 in d52ed99

	pub trait IntoPipeline<P: Platform, Marker = ()> {
	#[track_caller]
	fn into_pipeline(self) -> Pipeline<P>;
	}
	impl<P: Platform, F: FnOnce(Pipeline<P>) -> Pipeline<P>>
	IntoPipeline<P, Variant<0>> for F
	{
	#[track_caller]
	fn into_pipeline(self) -> Pipeline<P> {
	self(Pipeline::<P>::default())
	}
	}
	impl<P: Platform> IntoPipeline<P, Variant<0>> for Pipeline<P> {
	#[track_caller]
	fn into_pipeline(self) -> Pipeline<P> {
	self
	}
	}
	impl<P: Platform, S0: Step<P>> IntoPipeline<P, Variant<0>> for (S0,) {
	#[track_caller]
	fn into_pipeline(self) -> Pipeline<P> {
	Pipeline::default().with_step(self.0)
	}
	}
	impl<P: Platform, S0: Step<P>> IntoPipeline<P, Variant<1>> for S0 {
	#[track_caller]
	fn into_pipeline(self) -> Pipeline<P> {
	Pipeline::default().with_step(self)
	}
	}
	// Generate implementations for tuples of steps up to 32 elements
	#[cfg(not(feature = "long-pipelines-syntax"))]
	impl_into_pipeline_steps!(32);
	// Generate implementations for tuples of steps up to 512 elements.
	// This is opt-in through a compile-time feature flag and in practice
	// should never be needed, but it's here just in case.
	#[cfg(feature = "long-pipelines-syntax")]
	impl_into_pipeline_steps!(128);

Not a blocker, but a very nice to have to preserve consistency with the overall syntax.

[julio4]

I also had this in mind, but to keep things scoped what about not adding it directly and just relying on combinator implementation with macro?

[julio4]

I added the trait CombinatorStep that takes steps: impl Into<Steps<P>>, that should allows for adding this syntax

[julio4]

combinator! is a private macro that implements CombinatorStep with a struct with a vec of step instances.

One nice thing is that because CombinatorStep has Step as a supertrait, this force implementation of Step for the combinator step.

[julio4]

Following previous discussion, I changed to return Ok(initial) on Fail/Break.

What about deadline reached?

[karim-agha]

if the deadline is reached before all steps complete successfully then we don't have atomic result semantics and I would return the initial payload.

[karim-agha]

if the deadline is reached before all steps complete successfully then we don't have atomic result semantics and I would return the initial payload.