Hydrate one-to-many facts

[alex-dixon]

Should be relatively straightforward to implement. We maintain a one-to-many fact type distinction throughout the code so probably all that is needed is to performantly identify one to many facts at hydration time (maybe in listener ns) and group them.

[alex-dixon]

Reworked updating view model to accommodate one-to-many and one-to-one cardinality:

(defn apply-additions-to-view-model! [tuples]
  (doseq [[e a v] tuples]
    (let [ancestry (@s/ancestors-fn a)]
      (cond
        (ancestry :one-to-one) (swap! s/store assoc-in [e a] v)
        (ancestry :one-to-many) (swap! s/store update-in [e a] conj v)))))

(defn apply-removals-to-view-model! [tuples]
  (doseq [[e a v] tuples]
    (let [ancestry (@s/ancestors-fn a)]
      (cond
        (ancestry :one-to-one) (swap! s/store util/dissoc-in [e a])
        (ancestry :one-to-many) (swap! s/store update-in [e a] (fn [xs] (remove #(= v %) xs)))))))

In our current subscription model, views do not listen to the view model directly but instead receive subscriptions generated by rules. As a result, applications are not using this feature. We may however decide to create tools that observe changes to the view-model, though it seems dubious for those tools reflect parts of the view model the application does not use. However, our design should ensure that the view model is an object representation of the facts in the session and always in sync since it listens to every change to session state.

We are currently not indexing :one-to-many facts in fact-index, because we presume one to many facts can be inserted and retracted without negatively impacting session state. The fact-index should not be considered a candidate for tooling or public use generally, since unlike the view model it does not directly account for retractions that result from logical insertions.

[alex-dixon]

Fully implemented including subscriptions as of #52.