Memory Leak Fixes

[KD-92]

Describe the bug
When reinitializing the Simulator repeatedly, e.g., in a Reinforcement Learning (RL) setting, memory growth can be observed. Please find different fixes below (this is not a Pull Request due to the last item in the list).

To reproduce

1. ReactionWheelStateEffector Memory Leak
   In addition to issue #441, the destructor ReactionWheelStateEffector::~ReactionWheelStateEffector() in src/simulation/dynamics/reactionWheels/reactionWheelStateEffector.cpp uses free() on a data structure allocated with new. Additionally, it may be helpful to delete the elements of rwOutMsgs:

ReactionWheelStateEffector::~ReactionWheelStateEffector()
{
    for (long unsigned int c = 0; c < this->rwOutMsgs.size(); c++) {
        delete this->rwOutMsgs.at(c);
    }

    for (long unsigned int c = 0; c < this->ReactionWheelData.size(); c++) {
        delete this->ReactionWheelData.at(c);
    }
}

2. Missing Py_DECREF in SWIG Eigen Type Map
   There are missing Py_DECREF in src/architecture/_GeneralModuleFiles/swig_eigen.i in the fragment checkPyObjectIsMatrixLike. The changes are annotated with new decrement.

%fragment("checkPyObjectIsMatrixLike", "header", fragment="getInputSize") {

/*
This method returns an empty optional only if the given input is like the template type T.
Otherwise, the returned optional contains a relevant error message.
The size of the input is compared to the expected size of T (where dynamically
sized matrix T allow any number of rows/columns). Moreover, an error is raised for
ragged nested sequences (rows with different numbers of elements).
*/
template<class T>
std::optional<std::string> checkPyObjectIsMatrixLike(PyObject *input)
{
    auto maybeSize = getInputSize(input);

    if (!maybeSize)
    {
        return "Input is not a sequence";
    }

    auto [numberRows, numberColumns] = maybeSize.value(); 

    if (T::RowsAtCompileTime != -1 && T::RowsAtCompileTime != numberRows)
    {
        std::string errorMsg = "Input does not have the correct number of rows. Expected " 
            + std::to_string(T::RowsAtCompileTime) + " but found " + std::to_string(numberRows);
        return errorMsg;
    }

    if (T::ColsAtCompileTime != -1 && T::ColsAtCompileTime != numberColumns)
    {
        std::string errorMsg = "Input does not have the correct number of columns. Expected " 
            + std::to_string(T::ColsAtCompileTime) + " but found " + std::to_string(numberColumns);
        return errorMsg;
    }

    for(Py_ssize_t row=0; row<numberRows; row++)
    {
        PyObject *rowPyObj = PySequence_GetItem(input, row);
        Py_ssize_t localNumberColumns = PySequence_Check(rowPyObj) ? PySequence_Length(rowPyObj) : 1;
        if (localNumberColumns != numberColumns)
        {
            Py_DECREF(rowPyObj); // new decrement
            return "All rows must be the same length! Row " + std::to_string(row) + " is not.";
        }
        Py_DECREF(rowPyObj); // new decrement
    }
    
    return {};
}
}

3. Check for Msg disown()
   It may be of interest to verify whether <type>Msg.this.disown() is necessary in:

• src/utilities/fswSetupRW.py (writeConfigMessage(), rwConfigMsg.this.disown(), line 87)
• src/utilities/simIncludeRW.py (getConfigMessage(self), rwConfigMsg.this.disown(), line 379)

Expected behavior
With these changes, memory growth became unnoticeable for us even after millions of iterations.

[schaubh]

Howdy @KD-92 , thanks for the feedback. Something to look at in more detail. Regarding item 3., the reason we use disown() in the factory classes to ensure that the message memory is not released after being created in a sub-routine. There are likely better ways to do this that avoids creating msg objects which never get released