PODVector: Add extra capacity

[WeiqunZhang]

Add some extra room when we call PODVector::resize and reserve. The extra capacity is computed as 3*sqrt(capacity) suggested by @AlexanderSinn, and is capped at 10%. This might help particle codes avoid memory re-allocation.

[AlexanderSinn]

I feel like there should still be a way to resize a vector to the exact capacity that is asked for. Only if the vector is used in a particle container with multiple tiles where particles are exchanged using a thermal process is this a good strategy. If there is only one tile or if the vector is used to store a grid or metadata, the extra capacity is not needed.

[WeiqunZhang]

What's the downside?

[ax3l]

Can you pls add an inline comment or docstring for the logic here? It is not 100% obvious on first sight why s <= 900 caps the resize at +10% :)

[WeiqunZhang]

It does not really matter if we have a number that is not consistent with 10%. Anyway, I will add some comments.

[AlexanderSinn]

Just a waste of (a little bit of) memory. It also could get very confusing when trying to implement custom allocation size strategies on top of PODVector.

[WeiqunZhang]

Because it scales as sqrt(n), the extra memory cost is not an issue. As for implementing other growth strategies such as what are in #4735 , here is what I think. push_back and insert are rarely used and should not be used for GPU codes anyway. We probably do not care about constructors either. So our focus should be on just resize and reserve. In this PR, the growth strategy is implemented in function grow_podvector_capacity. It should not be hard at all to allow other strategies. In the current PR, grow_podvector_capacity is being used in 4 places. All we need is to have an extra parameter to the function, and the parameter can be obtained from the resize and reserve function as it's already being done in #4735. Re: ParmParse parameters in #4735, I think it's better to have them in particle containers, not in the vector class. I think that would be much more flexible and less confusing by having a fixed default in the vector and the change needs to be explicit. I think the default in vector should be that we have a little bit extra that scales as sqrt(n), because that cost is really not that much.