Filter element unintentionally stages its indirect runtime dependencies recursively

Summary

Instead of only staging and filtering its single build-dependency's files as originally intended ("Only stages the direct build-dependency, skipping indirect dependencies."), the filter element also stages its indirect dependencies recursively. This creates a situation in which a filtered element can contain more files than the element it filters.

Steps to reproduce

1. Download the following minimal reproduction example and extract it. Its element dependency graph is the following:

                           filters                  runtime-depends
   output-include.bst -----------------> input.bst -----------------> base.bst

2. Use the following commands inside the extracted directory:

   bst build --track-all output-include.bst
   bst checkout --deps none --hardlinks output-include.bst checkout/output-include.bst
   bst checkout --deps none --hardlinks input.bst checkout/input.bst

3. The contents of the checkout directory would then be the following:

   checkout/output-include.bst
   checkout/output-include.bst/foo
   checkout/output-include.bst/bar
   checkout/output-include.bst/base-system <--- from base.bst
   checkout/input.bst
   checkout/input.bst/foo
   checkout/input.bst/bar
   checkout/input.bst/baz

What is the current bug behavior?

As can be seen above, output-include.bst would additionally contain base-system, which was staged from base.bst.

What is the expected correct behavior?

base.bst is an indirect dependency of output-include.bst and should not have been staged nor filtered by output-include.bst.

Possible fixes

See MR below.

Other relevant information

• BuildStream version affected: %BuildStream_v1.2, %BuildStream_v1.4