[Core][PVS] Add PointerVectorSet::MutablePass to allow push_back safely.

[sunethwarna]

📝 Description
This PR adds the PointerVectorSet::MutablePass with the following properties:

1. There can be only one MutablePass issued per PointerVectorSet at a time.
2. The construction of MutablePass freezes methods which uses the sorted property of the PointerVectorSet
3. Once the MutablePass is destroyed, it sorts and makes the entities in PointerVectorSet unique. Then it unfreezes the methods which were frozen.

This PR also fixes the PointerVectorSet::operator[] and PointerVectorSet::operator() methods assuming they will be always sorted. This introduces a ❗BEHAVIOUR CHANGE❗.

🆕 Changelog

• Adds MutablePass
• Fixes the PointerVectorSet::operator() and PointerVectorSet::operator[]

[matekelemen]

this should not be public

[matekelemen]

I mean the ContainerType

[matekelemen]

LGTM, but I urge other members of the @KratosMultiphysics/technical-committee to take a peek as well.

[roigcarlo]

Duplicated

[roigcarlo]

I would change this (and the others) for:

ElementType::NodesArrayType nodes(geometry_size);

{
    auto mutable_pass = rElements.GetMutablePass();
    for (unsigned i = 0; i < num_new_elems; ++i) {
        for (unsigned j = 0; j < geometry_size; ++j) {
            const int node_id = mConnectivities(i, j);
            nodes(j) = rNodes(node_id);
        } 
        ElementType::Pointer p_elem = r_elem.Create(mIds[i], nodes, rProperties(mPropertiesIds[i]));
        mutable_pass.push_back(p_elem);
    }
}

While I like the idea of the MutablePass imho, it has a very big problem: You cannot control its life cycle and its correct usage its tied to it. I understand that this option is preferred over a Lock/Unlock mechanism over all the PointerVectorSet but if this is the case we should be careful while utilizing it and restrict it only to the scope in which is going to be valid.

While is not a problem in the usages that were modified in this PR because in very well encapsulated locations, I think it will become a concern later on, and at least this way we are hinting people that just copy/paste the code that they need to be aware of this detail.

[matekelemen]

The only way of ensuring correct usage would be getting rid of stuff that break the container's contract (such as push_back) altogeher.

This is unfortunately impossible because the KTC insists on having such features, so the next best thing @sunethwarna and I could come up with is this (= taking away as much control from the user as possible). Of course MutablePass can easily be misused (e.g.: heap-allocated) but I don't see anything we could do about that. We're more than open to suggestions though, just not ones that make it easier for users to break uniqueness/sortedness.

[roigcarlo]

Yep I understand, my only comment is, at least lets try to restrict the scope of the mutable to the minimum necessary

[sunethwarna]

@roigcarlo I agree, if there are ways to restrict the usage, we would be fully open. :)
@matekelemen: In the case heap allocation, if they keep the mutable pass alive, then all the functions which depends on the sortedness/uniqueness will be disabled, there is a high chance that the simulation will fail (not always for sure).

[sunethwarna]

One thing we can do to restrict full use when an MutablePass is issued is, to implement begin and end interators within mutable pass, and disable the iterators in the PVS. This adds a cost to normal PVS loops as well which I don't like, but it will for sure make the simulation fail, because i think 99% of the time we need PVS iterators.

[sunethwarna]

But my suggestion is to tell people how to use mutable pass, just as an std::lock_guard.

[roigcarlo]

using bracers as in the example should be enough, no need for complex solutions, that all was saying

[RiccardoRossi]

As we spoke, i have my own reservations avout this approach...but aside this.adds.an overhead tonesch [] as
And () access, even when the mutable stuff is.not there. In my opinion this one is a blocker...

[RiccardoRossi]

No go...you are adding an overhead to every access...