Clean up higher-level APIs

[saturnial]

Change List

• Remove Agreement base class.
  • All functionality folded into LoanRequest
• Loan becomes the base class from which Investment and Debt inherit
  • Most functionality lives in Loan.
  • Loan features fetch static initializer, which instantiates a generic instance of a child class from an ID
• Collection classes:
  • Investments -> query for multiple investments
  • Debts -> query for multiple debts

TODO:

• [ ] Tests for Loan, Investment, Debt
• [ ] Tutorials for Loan, Investment, Debt

[saturnial]

Let me share a bit more about the changes given that I haven't been able to convene @graemecode @chrismin to discuss all that I've explored in pulling this together.

• I don't export Loan because it's a type that we don't expect outside developers to use. So it shouldn't be confusing to external developers.
• Its purpose is basically code generation for us as internal developers. It houses the functionality that's shared between a Debt and an Investment and that shared code is automatically generated by typescript for us when we use the extends keyword.
• The shared functionality is also exclusively reading data. So you can think of a loan as an unopinionated look at a dharma debt agreement. It has no ability to mutate the state of the agreement. It's just a comprehensive window into its state as stored on chain.
• By unopinionated, I mean that it doesn't care about whether the object is being viewed by a debtor or creditor.
• In the case where the creditor is viewing the loan, they see an Investment where they can additionally seizeCollateral, which mutates states
• In the case where the debtor is viewing the loan, they see a Debt where they can additionally returnCollateral and makeRepayment -- again, mutating state

A few other notes:

• I investigated mixins. I think they're a pretty weak language feature. And I would argue against using them. I think they're confusing.
• When I first proposed this work, I was thinking of the protocol in Swift. Pretending like we have such technology when we're in Javascript is a bit of a farce IMO.
• Overall, getting too fancy in typescript is useless, because it ultimately compiles down to Javascript where types are not enforced and everything is just plain old objects.

Future proofing:

• I think it'll be relatively straightforward to introduce the idea of adapters to a lot of this work. You'd just pass the adapter into the constructor.

As for the size of the loan request class, the Agreement base class was polluting the namespace, and wasn't valid, because its underlying functionality only applied to LoanRequest. While large, the LoanRequest class IMO feels feature complete at this point.

[saturnial]

tl;dr:

• we shouldn't lean too heavily on typescript because the language we're ultimately writing in is javascript.
• we should be thinking in vanilla objects.
• using complex patterns that assume static enforcement is not actually providing value, because our end product won't benefit from this work and we'll diverge from our users.
• in conclusion, our API design should maximize readability and code reuse, not complex use of types.