Pre-calculate expiring block of postage batches at creation

[tmm360]

Currently expiration is calculate dynamically, updating the totalOutPayment variable, each time that price is updated.

This has downside that, when a postage batch is created, the owning user knows when the postage will expire only with current price. But if price changes, also the expiring date will change. This generated a bad UX, because it is not possible to schedule top ups having precise dates.

My propose instead is to pre-calculate the exact expiring block when the postage is created, for each postage. Users can purchase postages at current price, and this will be cost for their full life, regardless on price changes. This is acceptable, because doesn't open to new vulnerabilities (I don't see any), and make expiration predictable.

Other functions like top up and dilute can be implemented with this logic also.

Top up simply consider the current price at top up moment, calculate how many additional blocks of life you can add with the new amount, and simply add these blocks to the expiration block.

Dilute instead divide remaining live blocks per 2^(newDepth - prevDepth).

[significance]

this is interesting and i do like the ux, but it certainly changes a lot of assumptions!

i'll bring this up for discussion, thanks @tmm360