Revert lru_cache to functional form; Add lru-dict for integrators

[jsbrittain]

Description

Fix for excessive RAM consumption when running back-to-back simulations. As outlined in #1442, three problems were identified:

1. Use of the decorator @lru_cache on methods prevent the class instance from being garbage collected. Declaring lru_cache methods functionally in the initialiser resolves this problem. However, note that the function is no longer picklable, and instead the cache relationship must be removed and reinstated during pickling / unpickling.
2. Integrators are stored in a dictionary for re-use in CasadiSolver. Successive simulations with the same solver can cause the Solver object to grow unbound. A new LRU dictionary (LRUDict) has been introduced to limit the total number of items stored (along with appropriate test code). Default behaviour remains unchanged, but user-specification of an integrator limit permits simulations to run in a loop without unbound RAM consumption. Documentation has been updated to reflect the new parameter.
3. Successive caching of Solution histories, which can be solved by passing solution.last_state to Simulation.solve() (but requires resolution of [Bug]: Solution last_state can't be used as a starting solution #2788).

Fixes #1442 (Excessive RAM consumption when running multiple simulations)

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist:

• No style issues: $ pre-commit run (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
• All tests pass: $ python run-tests.py --all
• The documentation builds: $ python run-tests.py --doctest

You can run unit and doctests together at once, using $ python run-tests.py --quick.

Further checks:

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[brosaplanella]

Looks good, thanks! Just a small comment on the CHANGELOG.

[brosaplanella]

Can you move the comment further up (we follow a decreasing PR number sorting)? I realise some of the existing lines do not follow the order actually, so if you can sort them that would be great hahah.

[jsbrittain]

Sure, will do!

[brosaplanella]

@all-contributors add @jsbrittain for code and tests

[allcontributors]

@brosaplanella

I've put up a pull request to add @jsbrittain! 🎉

[martinjrobins]

thanks @jsbrittain. The one comment I had was the default of "unbounded" for number of stored integrators. What is the effect of having a finite bound by default (e.g. 100?), it feels like it would be nice to have memory consumption bounded by default.

[jsbrittain]

thanks @jsbrittain. The one comment I had was the default of "unbounded" for number of stored integrators. What is the effect of having a finite bound by default (e.g. 100?), it feels like it would be nice to have memory consumption bounded by default.

The default is unbound as this mimics the original code behaviour, but happy to apply an (arbitrary) bound, such as 100, if preferred.

[martinjrobins]

Thanks @jsbrittain, happy to merge.