Interface for framework driver

[knoepfel]

The current (experimental) interface of the framework driver allows constructions like:

void cells_to_process(framework_driver& d)
{
  unsigned int const num_runs = 2;
  unsigned int const num_subruns = 2;
  unsigned int const num_spills = 3;

  auto job_id = data_cell_index::base_ptr();
  d.yield(job_id);
  for (unsigned int r : std::views::iota(0u, num_runs)) {
    auto run_id = job_id->make_child(r, "run");
    d.yield(run_id);
    for (unsigned int sr : std::views::iota(0u, num_subruns)) {
      auto subrun_id = run_id->make_child(sr, "subrun");
      d.yield(subrun_id);
      for (unsigned int spill : std::views::iota(0u, num_spills)) {
        d.yield(subrun_id->make_child(spill, "spill"));
      }
    }
  }
}

Although this keeps the structure simple for users, it's not clear that it's ideal for the framework:

1. The framework determines the hierarchy of the data layers based on the d.yield(...) functions encountered.
2. If the framework knew the hierarchy before processing any of these yield functions, not only could the yield invocations be in vetted against the expected hierarchy, but it would also simplify the formation of the data graph.

We should discuss whether the simplicity of the current interface outweighs the two items discussed above.

[knoepfel]

Note that allowing the framework to know the hierarchy before executing the driver itself would result in a simple heuristic for the invocation of providers:

• If the provider provides a data product from a layer supported by the driver, then the provider reacts to messages generated from the driver
• If the provider provides a data product from a layer not support by the driver, then the provider reacts indirectly to messages generated from the driver (i.e. a relation must exist between the driver-supported layers and the provider's layer)