Support for PartitionProfile in resets

[JulStraus]

This PR adds support for updating nodes that incorporate PartitionProfile (introduced in TimeStruct v0.9.12) for some fields. Here, major problems are that

• PartitionProfiles must be consistent with the chosen horizon type and that
• PeriodPartitions are not inherent to a given time structure, and hence, require some further adjustments to the core structure compared to a simple additional reset.

Aside for these updates, it was possible to follow the standard approach oulined in the documentation.
It would also be possible to replace the EmptyReset with a different approach, i.e., remove the else statement in the inner constructor to

mutable struct PartitionReset <: AbstractReset
    lens::Union{PropertyLens,ComposedFunction}
    var
    val::PartitionProfile
    pps::PartitionProfile
    function PartitionReset(field_path::Vector, x)
        lens = _create_lens_for_field(field_path)
        val = lens(x)
        pps = period_duration(x)
        if val ≠ pps
            new(lens, nothing, val, pps)
        end
    end
end

and modify the add_elements! function to

function _add_elements!(𝒰::UpdateCase, 𝒳::Vector{T}) where {T<:AbstractElement}
    push!(get_sub_elements_vec(𝒰), _ele_to_sub(T)[])
    _init_mapping!(𝒰, 𝒳)
    for x ∈ 𝒳
        paths_oper = _find_update_paths(x)
        reset_types = [ResetType(field_id, field_id[end], x) for field_id ∈ paths_oper]
        deleteat!(reset_types, isnothing.(reset_types))
        reset_types = convert(Vector{AbstractReset}, reset_types)
        push!(get_sub_elements_vec(𝒰)[end], Substitution(x, reset_types))
        _add_mapping!(𝒰, x)
    end
end

It would reduce the number of resets, and hence, make the updating faster. However, it comes at the cost of the check within the add_elements! function and the convert. I am hence not certain that it is beneficial.

Note

I decided that it makes sense to rework the UpdateCase type to include both the main time structure and the receding horizon time structure. This update is however better located in a separate PR.

I also though of restructuring the test set a bit as we have, at least in my opinion some redundant code. This will also be a separate PR. This restructuring will not change any tests, only the structure of introduced types.

[JulStraus]

I realized that it is most likely necessary to also reset the PartitionProfile that is used for the durations of the individual partitions. However, I leave it as it is right now and also want to have your take on it.

[lfbernardino]

The functionality looks good in general, and I understand PeriodPartition will not be addressed in this PR. Some points of discussion:

• To answer your last comment: I think including EmptyReset in the package would be good for general functionality, in the sense that it is good to enable paths to not be reset, even if it goes against the philosophy of most cases. Having that said, I think that the general behavior should be that a partition duration referring to the receding horizon problem is a slice of the original problem, and hence it should be reset.

• Since partitions should not be split between RH optimization problems, I suggested a clearer comment on that on the docs.

• In the POI implementation, the number of partitions has to be constant across optimization problems, which is not currently explicit in the docs.

I suggest that you include the comments on the POI extension, and that you make the necessary changes for updating PartitionProfiles related to the duration of the partitions.