Generic Solution to disabled ListItems' Toast raising strategy

[MikeTrahearn-Qinetic]

Gui-v1 had a feature where ListItems such as MbSwitch would shadow the enabled property making it possible to implement a function where, while the ListItem would still be clickable even if the contained control e.g. switch) was disabled. In such a case a Toast would be shown indicating the reason why the control could not be changed.

This ticket to consider in more detail:

• how many such cases there are in gui-v1 where a toast is shown on a shadowed disabled ListItem
• how many cases in gui-v2 where the enabled property, being no longer shadowed, silently removes the toast showing feature
• consider in each case what the write access conditions are and which part of the control they apply to
• consider if there can be a generic solution
• size of work involved in fixing all the cases where it doesn't work in gui-v2

One such case is already documented here in PR 1814 which proposes one independent solution, but has been put on hold until this ticket resolves a more generic solution and a pattern that can be applied in all cases, having measured the scope of impact.

[MikeTrahearn-Qinetic]

Reviewing the following cases where ListSwitch uses onCheckedChanged rather than onClicked as a first step in this complex analysis; The following observations are made in the code when their onCheckedChanged is replaced with onClicked:

ListChargeSchedule::ListSwitch::118

• itemDay would no longer have its value set to toggleDay(itemDay.value))

PageSettingsGsm::ListSwitch(delegate)::171

• apnSetting would no longer have its value set to “”

PageSettingsGsm::ListSwitch::197

• This one is fine - it just clears the authUser and authPass on user demand and has a guard around it to prevent it from self clearing by accident.

PageSettingsHub4Peakshaving::ListSwitch::90

• The systemAcInputLimit would no longer be clamped at -1 or 40 - but only if userHasWriteAccess

PageSettingsHub4Peakshaving::ListSwitch::131

• The systemAcExportLimit would no longer be clamped at -1 or 40 - but only if userHasWriteAccess

DvccCommonSettings::ListSwitchForced::ListSwitch::20

• The maxChargeCurrent would no longer be clamped to 50 or -1

[blammit]

Created #1876 as a generic issue for reworking the enabled/click handling in ListItem.