Describe your motivation

ValueSignal is designed to allow sharing state across a cluster or between a server and a browser. For this reason, the actual value of the signal is an immutable JSON representation of the value. Every time you read the value, a new instance is deserialized from that JSON.

This leads to some runtime overhead and is also not practical for all types of data. We should provide an alternative that supports arbitrary values even though it cannot be directly shared outside the JVM where it's created.

Describe the solution you'd like

var selectedFile = new ReferenceSignal<File>(someFile);
add(new Span(() -> "Selected file: " + selectedFile.value().getName()));

The same mutation operations as on ValueSignal should be supported, i.e. value(T), replace(T, T) and update(UnaryOperator<T>). In addition, there's the possibility that the referenced value is a mutable instance that is modified in-place rather than by creating a new instance. There are several consequences of this difference:

1. The mutation methods will always trigger events for dependent effects and computed signals without being guarded by an equality check.
2. There needs a way of triggering events after a separate in-place modification, e.g. mySignal.notifiyDependents();
3. For external mutation, the developer is responsible for ensuring thread safety of the referenced object. We can help by providing a mutation method that runs an application-provided callback in a critical section: mySignal.mutate(value -> value.setFoo("bar"));. The mutation operations shared with ValueSignal should use the same critical section.

Additional context

The possibility of mutating the referenced object in-place means that the transactional capabilities of e.g. ValueSignal make no sense. We cannot provide repeatable reads, we cannot use the state from a ReferenceSignal as a condition in a transaction, and we cannot apply changes to the referenced object only if an asynchronous transaction is successful. For this reason, it should not be allowed to interact with a ReferenceSignal inside an explicit signal transaction (but the planned automatic repeatable-read transaction is still fine).

We should probably introduce a new WritableSignal interface or similar that allows using either ValueSignal or ReferenceSignal for e.g. two-way bindings with input fields.