feature: Workload propagation status for BindingPolicy about kubestellar HOT 2 OPEN

We should think of where it makes most sense for such information to be:

1. BindingPolicy/Binding: The BindingPolicy (BP) contains rules for selection while the Binding contains the actual objects. Does it make sense for propagation errors to appear here? They would be errors per BP, which means that they can come from any and every cluster selected

2. CombinedStatus: CombinedStatus is currently designed to be created only when at least one StatusCollector is applied to a selection rule (object test). CombinedStatus is per (object, BP). It might make sense to have a set of "invisibly applied" StatusCollectors that are extended to collect propagation information - through what @MikeSpreitzer proposed as Augmentations perhaps

3. A new resource

I think options 1 and 2 are very reasonable. There are tradeoffs to consider when scale is a factor.

from kubestellar.

The approach taken in #2055 is another possibility. One of the ideas there is that the status that can be combined includes an implicit augmentation by propagation status. It would be up to the author(s) of the combination(s) to decide how to combine/summarize the propagation status. Another of the ideas there is that the KubeStellar interface should be end-to-end and not get into details of the transport plugin.

from kubestellar.