rationalize computed values

[chadwhitacre]

This is proving to be a fair bit of work. On the pattern of #835, let's use a meta-ticket to track the multiple PRs it will take to get this done.

Early work was in #4045.

---

digraph G {
    "is_funded" -> "route.error" [dir=back]
    "funded payment instruction" -> "is_funded" [dir=back]
    "funded payment instruction" -> "amount" [dir=back]
    "giving" -> "funded payment instruction" [dir=back]
    "ngiving_to" -> "funded payment instruction" [dir=back]
    "receiving" -> "funded payment instruction" [dir=back]
    "nreceiving_from" -> "funded payment instruction" [dir=back]
    "distributing" -> "receiving" [dir=back]
    "taking" -> "receiving" [dir=back]
    "taking" -> "ownership" [dir=back]
    "ntaking_from" -> "ownership" [dir=back]
}

http://webgraphviz.com/

---

PRs

• is_funded—

[chadwhitacre]

Basically we want to start at the bottom and work our way up.

[chadwhitacre]

Or start at the top and work our way down?

[chadwhitacre]

http://knockoutjs.com/documentation/computedObservables.html

[chadwhitacre]

Refiling from gratipay/inside.gratipay.com#666 (comment):

Current status: feeling like we're chiseling with a screwdriver (i.e., wrong tool for the job) on #4063 #4065, and are now reading "Why developers should be force-fed state machines" (h/t).

---

We also read "Domain Logic and SQL."

[chadwhitacre]

We were finding on #4065 that for even a seemingly simple case, the interaction between different columns in an update can balloon into a complicated if/else tree when implemented inline in a procedural SQL trigger. @kaguillera worked out the effect of changes to team.{owner,is_approved,is_closed} on participants.ntaking_from: