Refactor holons zome into map_client, holons_guest, and holons_client crates

[evomimic]

1. Summary (Required)

What is the enhancement?
Split holons functionality into holons_core, holons_guest, and map_client crates. Holons zome is composed of holons_core and holons_guest. The map_client crate is composed of holons_core and holons_client. This encapsulates all holochain storage into the guest-side and allows caching and nursery logic to be shared by both client-side and guest-side. The map_client crate can be used by mock client test functions (i.e., sweetest) and potentially by TypeScript clients.

---

2. Problem Statement (Required)

Why is this needed?

1. Until now, our dance API has been returning references to staged holons via their StagedIndex. This requires client-side code (e.g., in "sweettest" functions) to duplicate the functionality that the Nursery offers on the guest-side on top of the StagingArea. This creates extra code to develop and maintain and adds unnecessary boiler-plate code to test functions.
2. Test functions cannot currently take advantage of client-side caching.

With careful re-factoring, the Nursery and HolonsCache functionality can be made portable (i.e., can be used on both client and guest side).

Benefits

• simpler, easier to debug test functions
• overall less code to maintain
• enhancements to core logic benefits BOTH client and guest
• potential to re-use map_client as a high-performance wasm library in TypeScript clients. This could significantly shorten MAP client side development and reduce maintenances.

---

3. Dependencies (Required)

None. But Issue #188 depends on this enhancement since it has changed the Command dance method parameter to StagedReference from StagedIndex.

---

4. Proposed Solution (Required)

The implementation checklist will be provided in a comment. Design issues for which some discussion of alternatives or complexities is warranted will be addressed in Discussion #198.

---

5. Scope and Impact (Required)

What does this impact?
This is a major re-factoring of the entire map-holons code base.

---

6. Testing Considerations (Required)

How will this enhancement be tested?

• No new functionality is being introduce, so no new test cases are required. However, dance tests that depend upon StagedIndex will have to be changed (simplified) to use the new map_client library functions.
• The map_client needs to be introduced into the test ecosystem?

---

7. Definition of Done (Required)

When is this enhancement complete?

• map_client incorporated in test client
• All existing test cases pass.

---

Optional Details (Expand if needed)

8. Risks or Concerns

The viability of TypeScript clients using the map_client as a WASM library remains to be determined, so it will be explored in a future enhancement. The current enhancement only includes sweetest usage of the map_client.

---

[evomimic]

Implementation Plan

This re-factoring is being done in branch 188.

Implementation Checklist

• Establish map_client, holons_guest, holons_core crates and migrate existing Holons modules to those crates

• Adjust Cargo.toml, lib.rs and mod.rs files to reflect the above changes

• Delete non-resolving "use" statements and re-import elements from the new structure

• Make HolonCollection portable -- move code with holochain dependencies to holon_service.rs

• Define HolonServiceApi trait in reference_layer

• Make GuestHolonService a service object that implements HolonServiceApi

• Inject the concrete holon service into HolonSpaceManager during init

• HolonSpaceBehavior should include get_holon_service and get_nursery methods to allow access to those services, rather than having the space manager mediate access to their api methods.

• Add "commit" function to the HolonServiceApi (it requires context parameter).

• GuestHolonService should delegate commit function to standalone commit_functions.

• Make Holon portable -- move code with holochain dependencies to holon_service.rs -- this is focus of Issue Move relationship_map out of Holon #200

• Make HolonSpaceManager sharable across client- and guest- (i.e., move it to holons_Core).

• Change the approach to ping-pong of staged holons -- the Nursery containing staged_holons as Vec<Rc<RefCell<Holon>> now exists on both client and guest. This eliminates the need to map staging_area to/from staged_holons. But (de-)serialization still needs to be addressed. This is addressed in Issue Replace Staging Area with Direct Session State Serialization #202

• Issue Implement the Client Holon Service #206 (Thomas) is addressing the following:
  - [ ] Split holon_dance_adapter into holon_dancers in holons_guest and holon_ dance_builders in holons_ guest.
  - [ ] add fetch_holon and fetch_related_holons dances (Thomas)
  - [ ] Implement ClientHolonService in holons_client (Thomas)
  - [ ] Make ClientHolonService a service object that implements HolonServiceApi for guest- and client-
  - [ ] ClientHolonService should build and invoke commit_dance

• Adjust core_schema_loader for new client-side capabilities

• Adjust dance_tests for new client-side capabilities