Configurable FlowBoundary interpolation

[SouthEndMusic]

Fixes #2281. Also fixes #2244.

Results with schematizations that look like this:

model = Model(
    starttime="2020-01-01",
    endtime="2020-01-09",
    crs="EPSG:28992",
    interpolation=Interpolation(flow_boundary="stepwise", stepwise_smoothing=7200),
)

fb = model.flow_boundary.add(
    Node(1, Point(0, 0), cyclic_time=True),
    [
        flow_boundary.Time(
            time=["2020-01-01", "2020-01-02", "2020-01-03", "2020-01-04"],
            flow_rate=[1e-3, 2.5e-3, 0.0, 1e-3],
        )
    ],
)

...

Old behavior:

New behavior with a smoothing period of 2 hours on either side of each data point:

New behavior without smoothing:

[visr]

This looks nice! Do you have any benchmark numbers that compare these three options, linear, stepwise hard, stepwise smooth?

[SouthEndMusic]

While making the benchmarks I came across a DataInterpolations bug:

SciML/DataInterpolations.jl#432

We need this to add the right tstops to our integrator if we use SmoothedConstantInterpolation

[SouthEndMusic]

Benchmarks:

• Stepwise interpolation without smoothing

BenchmarkTools.Trial: 184 samples with 1 evaluation per sample.
 Range (min … max):  5.859 ms … 33.363 ms  ┊ GC (min … max): 0.00% … 60.40%
 Time  (median):     6.862 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   7.431 ms ±  2.462 ms  ┊ GC (mean ± σ):  4.38% ±  9.25%

     ▄█▇▇▄
  ▄▇▅██████▅▇▇▆▅▆▃▁▄▃▃▃▁▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▃▁▁▁▃▁▁▃▁▁▁▁▁▃▁▃▁▁▃ ▃
  5.86 ms        Histogram: frequency by time        14.6 ms <

• Stepwise interpolation with smoothing of 7200 s

BenchmarkTools.Trial: 157 samples with 1 evaluation per sample.
 Range (min … max):   9.348 ms … 31.975 ms  ┊ GC (min … max): 0.00% … 53.83%
 Time  (median):     10.478 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   11.576 ms ±  3.008 ms  ┊ GC (mean ± σ):  6.19% ± 10.89%

     ▃▆█▃  ▃
  ▇▅▇█████▃█▅▅▃▄▄▃▄▃▃▃▁▃▁▁▁▁▁▁▁▁▁▁▃▁▃▁▃▁▃▁▃▁▁▁▁▁▃▁▃▃▃▁▄▁▃▁▁▃▃ ▃
  9.35 ms         Histogram: frequency by time        19.6 ms <

• Linear interpolation:

BenchmarkTools.Trial: 170 samples with 1 evaluation per sample.
 Range (min … max):  6.429 ms … 31.650 ms  ┊ GC (min … max): 0.00% … 61.35%
 Time  (median):     7.653 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.280 ms ±  2.587 ms  ┊ GC (mean ± σ):  4.32% ±  9.10%

    ▁ █▄▁▁▂
  ▄█████████▅▆▅▄▃▄▄▃▅▃▁▁▁▃▁▁▃▁▃▁▁▁▁▁▁▃▁▁▁▃▁▁▁▁▁▁▁▁▃▃▁▁▁▃▁▁▃▃ ▃
  6.43 ms        Histogram: frequency by time        16.4 ms <

 Memory estimate: 2.59 MiB, allocs estimate: 19759.

Notes:

• The DataInterpolations bug mentioned above is now solved on main
• Stepwise interpolation with smoothing leads to more tstops, so that probably has a significant impact here. It would be nice if we can see a significant performance boost w.r.t. not smoothing in more complex models
• Running these benchmarks gave me a nice demonstration of our latency problems, because the eltype of flow_boundary.flow_rate now depends on the new config option and changing the interpolation type leads to significant recompilation. @evetion do you think it would be better to change the eltype of flow_boundary.flow_rate to a union of the supported types, given that that union will remain small? That would mean some refactoring for the parameter parsing code

[evetion]

Ideally we keep the configuration as small/simple as possible, but if we need different interpolation types, are they global (all nodes), configurable per nodetype (all flowboundaries are stepwise) or configurable per node (😱)?

If per node(type), then we should have a config group with specific settings per nodetype. Otherwise we have a breaking change once we introduce this. Or, we determine stepwise_smoothing automatically and don't leave it up to the user.

[visr]

As discussed today, we'll go with block interpolation with 0 smoothing as a default. This PR needs to be updated to reflect that.