Navigate Pipeline via Pipes instead of Blocks

[georg-schwarz]

Until now, we have navigated over all blocks within a pipeline and connected them via pipes to get our execution order.
However, #485 will change that by allowing block definitions outside of pipelines, raising the necessity to iterate purely over the pipes with a pipeline.

This PR introduces a PipelineWrapper in the already existing of AstNodeWrappers that inhibits the functionality to navigate over a pipeline and replaces the existing helper methods in the model-util.

The PR should not change the behavior of Jayvee besides:

• Pipelines with one block but no pipes were previously valid, which is not the case anymore (see adapted tests).

TODOs:

• make it work for Pipelines
• make it work for CompositeBlockTypes (=> showcased by gtfs-static example)

[rhazn]

I left some comments for barely relevant things outside of the scope of this PR (e.g. GTFSExtractor and I am happy if you ignore them.

I am however happy to die on the hill of using DAG naming (parents, children etc) so I'd ask for reverting the renaming to followIngoing/OutgoingPipes.

[rhazn]

I know this is not part of the PR but this seems very boring. We could enhance the GTFSExtractor in the std lib to also include picking a file and parsing it as CSV, maybe as a composite block inside a composite block.

The new block could be called GTFSFileExtractor and take an url and a path as property, then use the existing GTFSExtractor with the url and the FilePicker with the file, then parse that file as CSV file. This would reduce this example by 3 blocks and 3 lines for every file (so 33 less blocks and 33 less lines in the pipeline itself!).

[georg-schwarz]

If you don't mind I'd leave it as it is for now.

But your example looks interesting, also in the face of optimizations. In the best case, we would also reuse executed blocks multiple times. I'm not sure if that would be the case in the current implementation, so I'd leave it open for a follow-up issue.

[rhazn]

Yeah, I agree on all counts, it's not in the scope of this PR anyway.

[joluj]

I thought about transforming it into the following so that astNode is typed better. I'm not sure if we have a benefit from that though.

Suggested change

	export class PipelineWrapper
	implements AstNodeWrapper<PipelineDefinition | CompositeBlocktypeDefinition>
	{
	public readonly astNode: PipelineDefinition | CompositeBlocktypeDefinition;
	export class PipelineWrapper<
	T extends PipelineDefinition | CompositeBlocktypeDefinition,
	> implements AstNodeWrapper<T>
	{
	public readonly astNode: T;

[georg-schwarz]

Awesome, seems to work now after removing the SimplePipe syntax in #487