API: Deprecation of specialized Step interfaces (InputStep, IndexableStep, etc.)

[eledhwen]

TL;DR

• Consider the deprecation of all or parts of the Step interface variants following the introduction of the StepRunner API (ie. the implementation of [old_issue]).
• One possible path would be to deprecate and then remove IndexableStep and PayloadStep while keeping InputStep as it sees more use and is more likely to be used for lambda steps

Details

They played an essential role in simplifying the API for a set of common use-cases for steps, considering the vast majority of Step implementations do not require half of its signature method's inputs.

Current Step variants are:

• InputStep which allows accessing the pipeline's argument, this is the most common use-case by a long mile
• PayloadStep which allows accessing the whole payload (ie. what was produced by the Initializer)
• IndexableStep which allows accessing the pipeline thread's object (ie. what was indexed by an Indexer after initialization)

The simplification happened by exposing relevant arguments in the variant contract, which helped with the having simpler method signatures for class-based implementations, but was also instrumental to making lambda implementations usable. It is important to keep in mind that [old_issue] cannot, by definition, concern itself with lambda-based implementations. Any measure taken here has to take into account the impact for both class-based and lambda-based implementations (even if the first type is a lot more prevalent).

Looking at the list of variants, the one obvious thing to note is that there are two families:

• one that cares about payloads
• one that does not care about payloads

In fact, this is mirrored with the pipeline builder API, where we have a slightly more compact builder implementation for pipelines that do not want to care about a payload (Pipeline.ofPayload and Pipeline.ofSimple), which is something we might want to address at some point.

One way we could tackle this issue, is by dropping support for less common patterns, and hold on "actually useful" variants. Before [old_issue] we needed variants for "all" expected patterns, now if the annotation-based mode is the preferred route, we could retain only Step as the reference, feature-complete, implementation ; and perhaps InputStep as a shorthand interface for easier lambda-based implementations.