Use best rate when ILP packet amount is zero

[justmoon]

As proposed in interledger/rfcs#313.

@michielbdejong suggested that overloading the existing packet format is a bad idea. In a general sense, I agree. As a practical matter, this patch is (as you can see below) very simple, breaks none of the existing tests (and doesn't break any existing ILP use cases) and allows us to build modern chunked/streaming payment transport layer protocols on our existing reference implementation. (Plan is that @emschwartz will start to work on back-porting the "ILP3" transport layer into the ilp module this week.)

I think the ultimate goal should be a cleaned-up ILPv2/BestEffort packet, where the amount is removed, see interledger/rfcs#323. However, I like the idea of experimenting with the new transport layer protocols right away and building this new packet using the experience gathered from that work. So I would urge us to adopt @adrianhopebailie's proposal (specifically the part about taking amount = 0 to mean best-effort) for now.

See also the sister PR for ilp-connector-shard: interledger-deprecated/ilp-connector-shard#4

[codecov-io]

Codecov Report

Merging #397 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #397   +/-   ##
=======================================
  Coverage   84.82%   84.82%           
=======================================
  Files          22       22           
  Lines         336      336           
  Branches       49       49           
=======================================
  Hits          285      285           
  Misses         51       51

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f95f82...fd61e4e. Read the comment docs.

[emschwartz]

I think we should wait for @michielbdejong's comments before merging this, but this sounds good to me.

In terms of whether we should go with this change or something like interledger/rfcs#323 in the long run, one of the questions we should consider is whether we want to continue to support the delivery behavior going forward or just deprecate it. If we want to support it, this seems like the best way to have both. Long term, I don't think we're going to have two different packet types going across the network (you could make the case that two functions baked into one type isn't much difference, which is probably true so we might need to pick one or the other anyway).

[michielbdejong]

Let's merge this now as a quick hack to unblock development; I created #398 as a follow-up PR where we can discuss the proper longer-term implementation.