Make operation more "transactional" and fix valuation inflation

[countvajhula]

Summary of Changes

• inflation of valuation was only taking the immediate payment into account and wasn't accumulating the amounts - fixed
• if an error was encountered it would sometimes already have made changes and things would be left in a weird state. Now we only write to disk at the end
• some docstrings
• rename some functions

Public Domain Dedication

• [x] In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.

(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)

[coveralls]

Pull Request Test Coverage Report for Build 4760561656

• 30 of 39 (76.92%) changed or added relevant lines in 2 files are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+8.4%) to 58.708%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
oldabe/money_in.py	24	33	72.73%
<!--	Total:	30	39	76.92%	-->

Files with Coverage Reduction	New Missed Lines	%
oldabe/money_in.py	4	60.28%
<!--	Total:	4		-->

Totals
Change from base Build 4760506795:	8.4%
Covered Lines:	170
Relevant Lines:	283

---

💛 - Coveralls

[countvajhula]

From an initial look at the precision error, it looks like the assertions assert sum(attributions.values()) == Decimal("1") are present at both read (input) and write (output) ends, and they both pass. Summing the actual written attributions up shows that the deviation from 100 occurs at a decimal position > 10, i.e. greater than our decimal precision. I tried setting the precision to 20 and this time the values totaled exactly to 100. This still doesn't tell us why there is a deviation at all, but it might be that when we add the "correction" to return it to total to 1, it is only able to verify that it is equal to 1 within the configured tolerance, but in fact it is not really equal to one and deviates at an insignificant position.

Yet, the following experiment doesn't shed much light on this:

> D = Decimal
> getcontext().prec = 10
> D("0.23000000000000001") == D("0.23000000000000000")
Out[3081]: False

... suggesting it detects a difference at that high precision level, but then:

D("0.23000000000000001") == D("0.23000000000000000") + D("0.00000000000000001")
Out[3092]: False

... suggesting it doesn't actually know at that precision level 🤔

And this:

> getcontext().prec = 30
> D("0.23000000000000001") == D("0.23000000000000000") + D("0.00000000000000001")
Out[3102]: True

[countvajhula]

I printed the actual values that are passing the assertion during a run of money_in and here's what I found:

> getcontext().prec = 10

> D('0.1710526317') + D('0.4934210526') + D('0.003289473684') + D('0.3322368421')  # the numbers that were printed
Out[3147]: Decimal('1.000000000')

> getcontext().prec = 20

> D('0.1710526317') + D('0.4934210526') + D('0.003289473684') + D('0.3322368421')  # the same numbers
Out[3152]: Decimal('1.000000000084')