Call publishPendingTags on all blocks rather than this scheduler

[mattkretz]

The call was originally introduced with 49adc04.

I'm not sure that my change reflects the intention. If it isn't, this needs a comment IMHO.

[mattkretz]

I see. This is not actually a Block<T>::derived_t type but a BlockModel. Then, what's the comment I could add to explain why I'm reading this all wrong? 😉

[wirew0rm]

I totally agree that this looks fishy, thanks for calling it out. 👍 I assume this was copied from a method inside of Block and then - when changing it to iterating over the blocks turned out to be non-trivial due to the needed APIs not exposed to the dynamically typed API - left this way and the required follow-up was missed. Should definitely have had a big // DO NOT MERGE YET comment.

I didn't fully follow it up now, but probably the way to go would be to only trigger the state change and implement publishing all pending tags in the Block's state handler and remove it from the scheduler.
On the other hand as it is, the code has been doing basically nothing all the time since it was introduced, so it might be also possible to drop it. I'll have a look.

[mattkretz]

I believe it should be possible to publishPendingTags on the ports of the block behind the BlockModel by introducing a new virtual function to BlockModel (implemented by BlockWrapper). Whether that's necessary 🤷

[wirew0rm]

I discussed with @drslebedev and we agreed that with the recent changes in tag handling and considering the fact that the line in it's current form is not doing anything since the scheduler does not have any ports, the correct solution is to remove the line alltogether. I'll update this PR to that effect.

[drslebedev]

LGTM as discusses privately with @wirew0rm. PR can be merged.

[RalphSteinhagen]

I discussed with @drslebedev and we agreed that with the recent changes in tag handling and considering the fact that the line in it's current form is not doing anything since the scheduler does not have any ports, the correct solution is to remove the line alltogether. I'll update this PR to that effect.

The scheduler is derived from Block<T> and inherits its message ports. The UI would trigger/accept messages from that port:

class SchedulerBase : public Block<Derived> {
    friend class lifecycle::StateMachine<Derived>;
    using JobLists = std::shared_ptr<std::vector<std::vector<BlockModel*>>>;