Prune initialState files & amount of data saved with each design

[grumpyinca]

It appears that there are opportunities to size-reduce initialState files as well as the amount of data saved with each design. Reducing the size of designs saved into the production database can slow the growth of the database and thus push off the time when it will be necessary to move to a more expensive tier of database hosting.

The most obvious first move is to not store the values of dependent variables. These values are unnecessary because on opening a design from the database, the values of all dependent variables are immediately recalculated from the current independent variables and calculation inputs. The process of saving a design will need to set values of each dependent variable to something short. Perhaps a null string ('') will work best. This would be preferable to the value appearing as "null" or "undefined". While a bit of investigation may be required to confirm, perhaps the values of smin / smax can be treated the same way.

It may also be possible to avoid repeating the tooltip associated with each symbol table entry. It is likely that there are multiple approaches. Perhaps a new database table can contain a list of strings. The stored value of tooltip could be the index into this list.

[grumpyinca]

This issue overlaps with #816 (now closed):

Calculation Input members of the symbol table (initialState, Startup designs) for the various Spring design types contain unused property entries, for example: lmin, lmax, cmin, cmax, sdlim. These entries contribute to unnecessary data size and are a potential source of confusion. These entries should be removed.

[grumpyinca]

Today's discussion came up with a perhaps better approach. Specifically, the existing initialState files can be thought of as a "template" that contains all information about a design. When exporting or saving into the database, only the information that is potentially changed by user input and not re-generated should go out. When coming back, that information can be merged with the appropriate initialState in order to re-create the desired instance of the model.

Having less information stored in the database and Export files means that a specific design has a smaller "footprint" that is exposed to version change ... thus potentially less migration required. The information that is not subject to change as a result of user input will move forward as the initialState (template) moves forward from version to version.