Investigate debounce time

[louispt1]

We should investigate the debounce time for sending requests to the API. A longer debounce time could improve efficiency by batching multiple changes into a single request, reducing the number of calls made to the Engine. However, this comes at the cost of increased delay for processing single-input updates.

The goal is to find the optimal debounce time that:
1. Reduces excessive API calls when users make multiple updates in quick succession.
2. Minimizes delay to ensure a responsive experience for users who are updating a single input at a time.

Key Questions:
• How frequently are users likely to make quick successive updates, and how quick will they be?
• What is the perceived acceptable delay for users between input and response?

[mabijkerk]

In addition to debounce, we could investigate other options to smoothen the interaction of the user with the interface. Suggestions:

• Adding a "calculate" button, disabling it will allow the user to set sliders with the model running the calculations
• Re-calculations seems to be triggered by new charts (and slider changes of course), though sometimes users only want to set a new slider, without having to see the new slide. Perhaps something smart can be done here