Define GFD UI scenarios to inform which API fields & relationships are needed

[pospi]

• maximise number of UIs we can demo on a small set of API fields, if possible
• otherwise, go for smallest set of fields first
• attempt to favour the fieldset that @sqykly has built support for in the backend

In an ideal world, this task can be done by inspecting the GraphQL bindings for the UI (per #2) in whichever app(s) are chosen for deployment.

[pospi]

I'm re-wording this slightly and assigning to @fosterlynn & @bhaugen to get some clarity, as it still doesn't seem clear what we want to show for the "Good First Demo".

At this stage @fosterlynn asserts that we probably want to build GFD on top of features that @sqykly's backend already supports, rather than trying to implement more stuff. Broad agreement about this plan.

However the exact dependencies based on what we'd like to show in the UI, what needs to be "real", what should be mocked, how that corresponds to GraphQL queries (and whether those queries should differ from a "real" REA implementation such as NRP for the demo), and whether there is support in the DHT code to service those queries... all remains unknown. This will be a difficult thing to coordinate.

The way we've currently talked about working through this is as follows:

1. @fosterlynn @bhaugen & @ivanminutillo decide on a simple demo concept that they think is achievable, and do a quick sense-check with @sqykly to confirm that the DHT code is able to service the requirements.
2. @ivanminutillo goes ahead and modifies src/ui as necessary to wire it up to the REA GraphQL API that he would expect to be building on. So long as the react-redux provider and store are retained, pretty much anything else can be changed. It would also be good (but not mandatory) to keep the GraphiQL query interface present under its own route (aim for this, but don't waste time on it if it's a problem).
3. @pospi takes the GraphQL queries written by @ivanminutillo as they are completed and wires up GraphQL -> Holochain bindings to implement them. In the process of doing this he tries to abstract away as many common patterns as possible so that the effort involved in wiring up GraphQL fields is continually reduced. He will likely have to coordinate with @fosterlynn & @sqykly as he goes to ensure the way he's wiring things up is correct.
4. Once they're wrapped up to an adequate degree, @pospi can hand off some of the GraphQL query implementation work to @fosterlynn so as to get the job done faster.

[fosterlynn]

Here is the latest documentation (outside of the code) that I have on the scenario that @sqykly has put together (tweaked in minor ways by me). https://github.com/valueflows/valueflows/issues/385

David, is this still correct? Please let me know about any changes. I can spec graphql queries based on the current scenario.

[pospi]

I think in terms of GFD we are done except for track/trace functions. Any other specifics we want can be raised in other issues.