Add caching dependency

[PhilippeMoussalli]

Current implemented caching does not take into account the previous component cache key when estimating the cache key. This can be an issue in some scenarios, for example:

1st run: load_from_hub (input_dataset=x) -> download_images
2nd run: load_from_hub (input_dataset=y) -> download_images

In the second run, the download images component won't execute and will be cached since it might have the same input arguments as the first run. However, both runs start from different input datasets and thus the second run would actually end up loading in the dataset cached from the 1st run.

This PR addresses this by including the hash key of the dependent component in the component cache key estimation.

[RobbeSneyders]

Are we using the input_manifest_path to calculate the hash key as well? I assumed we were, and I would expect it to change whenever the hash key of the previous component changes.

[PhilippeMoussalli]

Are we using the input_manifest_path to calculate the hash key as well? I assumed we were, and I would expect it to change whenever the hash key of the previous component changes.

We're not using it. The path of the manifest does not change depending on the hash key and is always resolved to a path that contains the run id the current running pipeline.

The save path looks like this at the moment

save_path_base_path = (
    f"{manifest.base_path}/{manifest.pipeline_name}/{manifest.run_id}/"
    f"{manifest.component_id}/manifest.json"

[RobbeSneyders]

Ok, thanks for the explanation. I had some misassumptions about how the caching works, but this seems logical. Small comment below.

[RobbeSneyders]

I think we can remove the if/else check here, since we check it inside get_component_cache_key()

[PhilippeMoussalli]

ahh yes, good catch