First Cut Of Web UI

[azriel91]

Related: https://github.com/azriel91/peace/issues/125

Use leptos and dot_ix to create a first cut web UI:

1. Render flow graph
2. Buttons to invoke commands
3. Render progress
4. Render outcome

Interactively rendering additional information, or highlighting the parts of the outcome when the progress step is hovered (or vice versa) is not necessarily in scope.

[azriel91]

For rendering the flow graph, perhaps the following works:

1. [x] Create peace_flow_model, and define a FlowSpecInfo which is essentially the Flow without logic.
2. [x] WebiOutput, is instantiated with FlowSpecInfo, which is passed to a <FlowGraph flow_info=flow_info cmd_progress=cmd_progress /> component.
3. [x] FlowGraph uses dot_ix to render the graph -- specifying the nodes and edges.
4. [x] In impl OutputWrite for WebiOutput, the Progress* updates are used to change the WriteSignal<CmdProgress>, which influences the tailwind_css styles passed by FlowGraph to dot_ix.

[azriel91]

Refactorings to make drawing the outcome diagram easier:

1. [x] Rename peace_resources to peace_resources_rt.
2. [x] Rename Item to Step decided this doesn't make sense.
3. [x] Create peace_resource_model to house the ResourceInteractions type, which represents:
   • From/to interactions between two resources.
   • Modification of n resources (e.g. 3 servers all have X patch applied)
   • Security group affecting n servers modified

Perhaps we do the first two as part of https://github.com/azriel91/peace/issues/187 first, then continue this.

[azriel91]

Things to do:

1. [x] Rename Resource* to Item*.
2. [ ] Change ItemInteraction API to clearly represent nesting vs multiple resources being interacted with -- probably create ItemInteractions.
3. [ ] Move Flow into flow_rt crate.
4. [ ] Gate flow_spec_info and related types behind feature = "resource_interactions".
5. [ ] Add ItemInteractions in ItemSpecInfo (and ItemInfo?).

Changing ItemInteraction API

1. Retain ItemLocation as is, but create one of:

   1. ItemLocationAncestors which is a Vec<ItemLocation> newtype.
   2. an ItemLocationTree which is a struct { ItemLocation, Vec<ItemLocationTree> } -- a parent ItemLocation, and any children it has. Or should it be a Map<ItemLocation, Vec<ItemLocation>>? (flat map so it's easy to see if an ItemLocation is already recorded)

2. How about both:

   1. The ItemLocationTree is the tree of the topmost (known) ItemLocation ancestor, to all of the lowest ItemLocations.
   2. The ItemLocationAncestors is a linear list from the topmost (known) ItemLocation ancestor to each leaf ItemLocation -- one path of an ItemLocationTree.

3. For each Item's interactions, we want to know:

   1. The source ItemLocation(s?) -- ItemLocationAncestors.
   2. The destination ItemLocation(s) -- Vec<ItemLocationAncestors>? or ItemLocationTree, where each leaf node is a destination.

   Other names considered for ItemLocationAncestors are:

   • ItemLocationAncestry
   • ItemLocationTaxonomy
   • ItemLocationLayers

   Use cases we know of:

   1. Upload a file -- one source, one dest.
   2. Download a file -- one source, one dest.
   3. Launch servers -- one source (localhost), one dest (AWS).
   4. Wait for servers to start up -- multiple within (do we need the ItemLocationTree for the cloud provider / subnet context? or leverage previous resource tracking to work it out?).
   5. Wait for endpoints to become available -- one source, multiple dest (query each endpoint).
   6. Do we want ItemInteractions to be queried multiple times while Apply is happening? -- i.e. some servers may have started up, and so we need the Item to report that to us.
   7. Notably, we want these ItemInteractions to be queriable without the items actually existing -- so we can generate diagrams to demonstrate what would happen upon execution.