LinearBatteryPlugin stability improvement

[ntfshard]

🦟 Bug fix

Fixes #

Summary

This PR contain 3 different changes

• LinearBatteryPlugin: startDraining should be atomic due to we are changing it in callback which can be called from other thread (valgrind --tool=drd or helgrind)
• LinearBatteryPlugin: In a C++ each type has own alignment and rule of thumb: sort fields in order from bigger to smaller to avoid creation padding between fields. For structures we can add compiler option -Wpadded to get warnings, but we can't do it for a project due to reports not only padding between fields but also in case of inheritance (and we have some case with quite base types). So I propose to reorder some members to avoid such padding
• battery_plugin: in this test we had a logical race condition: when we publishing message, propagation can took some time. And if we are starting simulation immediately in some cases(e.g. VM or overloaded CPU) we can get couple of iterations of simulation until we receive the message. So it's more durable to send message and spin a little bit to be sure of delivery

It's quite simple to add some keys to compiler just by defining some env.variables before a clean build execution

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[caguero]

Nit: Do you mind to use camelCase here?

[caguero]

Nit: Do you mind to use camelCase here?

[caguero]

Thanks for the patch! Agreed on your 1) and 3) points. About 2), not sure about the impact of that optimization because there are other aspects to be considered as well (are members used together, etc.). We normally don't consider that type of optimization when programming. In any case, it's absolutely fine your proposal of rearranging the member variables as I think is harmless, just saying that without seeing numbers I'm not 100% convinced about its impact :)

In any case, this topic is super interesting and we usually don't pay much attention to it. If you're interested in these kind of optimizations we could try to explore them in more depth trying to consider alignments with cache lines, etc. and measure the impact of the changes.

[ntfshard]

alignments with cache lines, etc. and measure the impact of the changes.

It's not about alignment with cache lines (for this we have alignas and it's more about false-sharing)

It's more about memory throughput. For a big structures or if we have just few instances it's maybe has lower impact.
In this particular case, it was 456 and became 432 bytes. So it's -5% (measured with hack ).

Still optimization is a very big topic, I done it here maybe almost automatically, and TBH, I more interested in more convenient and productive usage of simulator, but my resources as a contributor are very limited