Option to ignore previous state in AsyncValue by default

[Barabas5532]

Is your feature request related to a problem? Please describe.

I have found that in most places in my app, I want to use .unwrapPrevious() on AsyncValues so that the UI correctly reverts to a not interactive loading state when connection to some service (embedded hardware with websockets interface) used by my app is lost.

It is a real time application, so I don't use offline first design. The connection is robust enough to never drop out randomly, but it can disconnect if there is a firmware crash or I load a new firmware version during development. While the connection is not present, most UI is grayed out until the hardware connects again.

If I forget to write .unwrapPrevious, then the UI will look like it's still usable, even though the connection to the hardware has been lost, and every operation the user might attempt will error out.

Describe the solution you'd like

Add some kind of compile time option to invert the default and modified behaviour of using the previous state.

New option off (default, current behaviour):

Extra typing is required to disable using the previous state.

• AsyncValue.valueOrNull: Return current value or previous value if current state is error or loading.
• AsyncValue.unwrapPrevious().valueOrNull: Return value only if current state is data.

New option on (explicitly enabled, proposed behaviour):

Extra typing is required to enable using the previous state.

• AsyncValue.valueOrNull: Return value only if current state is data.
• AsyncValue.withPrevious().valueOrNull: Return current value or previous value if current state is error or loading.

Similar changes to every other function that uses the previous value by default in the current implementation.

Describe alternatives you've considered

We can just make sure to type .unwrapPrevious everywhere, but it's too error prone.

Additional context

Another request for the same feature in an old comment: https://github.com/rrousselGit/riverpod/issues/2097#issuecomment-1398000811.