Create polished abstractions for graph-like record storage

[pospi]

This basically means bringing the work @sqykly has been doing on reproducing LinkRepo into the shell of the end-to-end system and validating the architecture by implementing our first inter-DNA bidirectional link.

Most of the groundwork and underlying architecture will be similar to the structure shown in these diagrams, and most questions needed per #3 have been answered. Additionally, it is also clear that if one defines a "record" as a single logical entity within a Holochain app then there are actually multiple DNA primitives involved in constructing that representation.

It has been observed and discussed that there are some common emerging patterns for record management on Holochain:

• @sqykly referred to these as "link constraints" in discussion of whether links should have a "bidirectional" attribute added as a "constraint" when building the link index.
• @pospi calls these "link components" or "link behaviours" and wants to use them as low-level declarative building blocks for building up record storage & query structures. We can work towards these simply by wrapping up common functionality as we go. @pdaoust has also expressed a desire to build up 'small composable helper functions' out of what the HDK provides, we hope eventually this process will yield a new set of simplified methods in hdk::utils.
• @lucksus has spoken about the extra utility to be found in aggressive decomposition of Holochain app modules into smaller chunks- for example, a separate 'link broadcasting' DNA which tracks the linkages between records in two cooperating DNAs would allow inter-network connectivity to be analysed and broadcast the appearance of new networks into the ecosystem.
• We've also discussed Holodex with @artbrock, which was a standalone DNA for indexing content on other DNAs (kinda like plugging in ElasticSearch in a traditional cluster); and it seems clear that some features will need to interact with bridged DNAs whilst others will be internal logic.

These things being the case, the evolutionary pattern is likely to be:

1. higher-order wrapper functions emerge to take care of managing common data structures (in our case, graph databases), and are integrated into DNA zome handler code
2. some low-level utility DNAs will also emerge, which require external state to be managed in independent networks by way of bridging; in addition to integrating with other DNA code
   • these 'utility' DNAs are likely to have separate user interfaces (in the case of Holodex, a search UI; in the case of link broadcasting, a network map)
   • also likely to have pre-deployed 'recommended' public networks (eg. "the hApp of hApps")
     • will be pairwise modules: 1 side is the DNA; the other side is the utility crate/module to provide wrapper functions for interacting with the microservice
3. hApp developers then begin to see system behaviours as pluggable, declarative mixins to their zome code...

Progressing through this implementation process should land us on a stable, polished foundation to build out the rest of the app on. This is likely to lead to the creation of some URI resolver logic to more reasonably handle cross-DNA record linkage.

This issue is a place to talk through the high-level design of our graph-like record structures. The lower-level tasks encompassing this work (so far) can be found in #18, #19, #20, #21 & #22.

The other reason to log this task separately is to claim it as a milestone. We should not proceed beyond the implementation of our first set of relationships (satisfactions & fulfillments) until we are happy with the code structure and quality, and comfortable building out the rest of the app to the same standard.

[sqykly]

LinkRules already does bidirectional declaratively as well as singularity and three entity systems like parent/child/sibling.

[pospi]

Just noting that when it comes time to wrap all this work up, we should make sure the unchecked items in https://github.com/holo-rea/holo-rea/issues/14 have been covered in the process.

[pospi]

No need to chcek #14 any longer, all relevant items have been duplicated from there into newly logged issues.

[pospi]

This has evolved into finishing hdk_graph_helpers, which may have all functionality required already but we won't know until #37 is decided and #42, #39 and possibly #40 are completed.

[pospi]

Closing this- only #39 and #40 are still outstanding with latest updates in #59, and can be addressed independently.