Delay dialing the VM exec server (#8296)

The dial doesn't succeed until the VM exec server is healthy, so we
might as well give it so more time to start and do other work in the
meantime. I think this will reduce the dial latency by at least 100ms.
For actions that take more than 1s to createWorkspaceImage, I think this
will nearly eliminate the dial latency.

enterprise/server/remote_execution/containers/firecracker/firecracker.go

@@ -1283,17 +1283,21 @@ func (c *FirecrackerContainer) createAndAttachWorkspace(ctx context.Context) err
 		return nil
 	}
 
+	workspaceExt4Path := filepath.Join(c.getChroot(), workspaceFSName)
+	if err := c.createWorkspaceImage(ctx, c.actionWorkingDir, workspaceExt4Path); err != nil {
+		return status.WrapError(err, "failed to create workspace image")
+	}
+
 	conn, err := c.vmExecConn(ctx)
 	if err != nil {
 		return err
 	}
 	execClient := vmxpb.NewExecClient(conn)
 
-	workspaceExt4Path := filepath.Join(c.getChroot(), workspaceFSName)
-	if err := c.createWorkspaceImage(ctx, c.actionWorkingDir, workspaceExt4Path); err != nil {
-		return status.WrapError(err, "failed to create workspace image")
-	}
-
+	// UpdateGuestDrive can only be called after the VM boots (https://github.com/firecracker-microvm/firecracker/blob/c862760999f15d27034098a53a4d5bee3fba829d/src/firecracker/swagger/firecracker.yaml#L256-L260)
+	// The only way to tell if the VM booted seems to be monitoring its stdout.
+	// Instead we'll just wait for the vm exec server to start above, which
+	// happens after boot.
 	chrootRelativeImagePath := workspaceFSName
 	if err := c.machine.UpdateGuestDrive(ctx, workspaceDriveID, chrootRelativeImagePath); err != nil {
 		return status.UnavailableErrorf("error updating workspace drive attached to snapshot: %s", err)