[launch] consider refactoring ExecuteProcess into Execute and Executable

I believe it might be wise to separate the description of a process to be executed and its state while running from the Action which executes it.

Currently all of this information is encapsulated in the ExecuteProcess action, and my proposal would be to replace that with an action called Execute that takes an Executable (not an action or launch description entity, just a new kind of class). The Executable would contain any information needed by Execute to actually execute the executable described or introspect it. There could be sub classes of both Execute and Executable. For instance, a sub class of Executable might be Node or LifecycleNode, and a sub class of Execute might be ExecuteRemotely (execute on a different machine).

The reasons for doing this include:

• using Executables (or subclasses thereof) with other actions
• cleaner abstractions
  • i.e. the ExecuteProcess class is really big now and it would be nice to break into smaller parts
• more readable
  • e.g. Execute(Executable(...)) or Execute(Node(...)) rather than ExecuteProcess(...) and Node(...)

The first reason is the most impactful, because it allows for a few use cases that aren't currently easy to implement:

• Collect or generate Executable instances and later decide whether to pass to Execute, ExecuteRemotely, or ExecuteInDocker (just ideas)
• Pass ComponentNode (possibly a subclass of Executable which represents a node that can be loaded dynamically) to either Execute() or ExecuteNodesInSharedProcess() (name needs work)
  • where the latter would take several ComponentNode instances and run them all in a single process

I still have some design questions in mind, like:

• should Node inherit from Executable
• should Executable contain process related things like pid and produce events for stdout and process exit, etc...
  • or should there be a Process that also inherits from Executable
  • because Node might not be associated with a process, or rather a process might not be associated with a single Node
• what is the contract between Executable and Execute?
  • which creates event handlers and stores information?
  • what exactly are the responsibilities of Execute?

Start by reviewing the existing ExecuteProcess action and its uses in the launch codebase. Work through the proposed Execute and Executable responsibilities, including Node, process state, events, and remote execution. Done requires an agreed design for the abstractions and a coordinated implementation plan.