[DDS] Add support for setting initial service extension values from DDS

[kenzieschmoll]

A service extension may need to be called before an app starts up. From a tooling perspective, this is often to set an initial value for a service extension. For example, in DevTools currently, we have to queue these calls as pending, wait until the Flutter.FirstFrame event is received, and then issue all outstanding calls to service extensions.

It would be ideal if DDS act as an intermediate layer to handle this use case. DDS could receive these calls, then manage executing the calls immediately on startup. This would avoid the problem of managing the race across tools. I am working on a feature in flutter tools currently that likely will also run into this race issue, where I need to set the value of a service extension but will have to make sure the device has started up.

@bkonyi @jacob314

[jacob314]

We can't just use dart environment variables to handle these cases because environment variables aren't supported on all Dart platforms we need to support.
It could be that changes to support this need to be partly in the VM Service itself. A reasonable division might be that the VMService allows accepting payload to immediately call a service extension with on isolate start and DDS supports persisting setting values for service extensions across isolates.

Another component of this FR could be codifying the flutter concept of boolean and string value service extensions that act like getter setter pairs in dart:developer.

[bkonyi]

I'm not sure I'm clear on how we can issue service requests before the application starts up and starts advertising its VM service URI. DDS won't be started in any context until a VM service is available. Am I missing something here?

[bkonyi]

Going through my backlog. Is this issue still relevant?

[jacob314]

This is still relevant. Flutter has adopted some good conventions for service extensions that get and set values that that should be promoted to dart:developer and the VMService rather than as just a convention in the Flutter code base. With those conventions, the semantics for setting values immediately on VM startup become clean.

See registerBoolServiceExtension, registerStringServiceExtension, registerNumericServiceExtension, registerNumericServiceExtension for the existing Flutter apis.
https://github.com/flutter/flutter/blob/852bfe2a73e2ca059c1a0031879101231b946f5f/packages/flutter/lib/src/foundation/binding.dart#L652
The functionality for these APIs would be refined slightly to support immediately invoking the setter if a default value has been set before the service extension was registered. Only the very last default value set needs to be applied in case multiple VMService clients set a value. Getters cannot be called before service extensions are registered.

I think it would make sense to add helpers with exactly this bool, String, and num service extension behavior to dart:developer. Setters could be called on VM startup with the last value set applied as soon as the service extension is registered.