Use item::energy to stash sub-kJ power quantities for more precise power usage

[kevingranade]

Summary

Bugfixes "Allow tiny continuous power draw in electronic devices."

Purpose of change

TODO find related issues
We've had issues with low-draw devices that are supposed to work for a very long time for practically forever. There are workarounds such as tool::turns_per_charge, but that's gnarly and has weird side effects.
The root cause is that the lower bound of charge resolution has been "one battery charge", which we set at 1kJ because there's also a rather large number of charges we need to handle for e.g. electric cars, and the "number of charges" type is an int.

Describe the solution

I poked around and we already have a member of the item class that is type units::energy which is backed by a int64_t and has a resolution of one mJ. Due to an int64_t being staggeringly large, this really can handle whatever we feel like throwing at it, so why isn't the problem fixed?
The problem is legacy code that treats electrical capacity as "charges" and a whole ton of infrastructure, mostly in crafting code, and specifies power drain in "charges of battery", which again are 1kJ each.
After rooting around though, I realized we don't have to overhaul all the crafting code to fix this particular issue, because the "process_tool()" code responsible for e.g. spending power every turn for an active flashlight doesn't interact with any of that code.
So what I've done here is I updated item::process_tool() to call item::energy_consume() and item::energy_consume() to use item::energy to stash residual energy as needed. So if your flashlight has 10 "charges" of battery and you try to spend 20J, it spends one "charge", but stashes the remaining 980J of energy in item::energy, which can be used next turn instead of burning more charges.

Describe alternatives you've considered

There's a huge overhaul I eventually want to happen here where the itype_battery item that represents a distinct amount of charge just goes away and instead a battery item like a light_battery instead just uses it's item::energy member and islot::battery::max_charges member to handle how much charge it can hold. That requires overhauling a huge amount of crafting code though and I'm not up to that at the moment.

Testing

Added tests for an exemplar, specifically having a small LED flashlight run for the intended 10 hours on one set of batteries.
Before this change it would round up from 1.5J per turn to 1kJ per turn, so it would run for one hour instead of about 10.

Additional context

See e.g. #75903 for other aspects of the same problem.

[Hydrogen-Deuteride]

I think this "stash" thing should be on battery side. So then it can be also used to limit how much energy battery can output in 1 turn(essentially max power of the battery), so we dont have this situations when 10g battery released 2kJ of energy in 1 turn which is like 2kW of power provided.
Also player should see how much sub charges remains.

Unless this is just temporarly hack untill battery system overhaul.

[kevingranade]

It is on the "battery" side, an example of a "battery magazine" is a lithium ion battery pack in a phone, or a AA battery cell.
The actual "battery" itype is a massless, volumeless unit of charge.

[GuardianDll]

Can't get how does it work json side? Does it just allow "charges_per_use: 0.5, or it allows string notation now?
Unless i misunderstood, and it doesn't actually cover electric tool activation?

[kevingranade]

You could already specify "power_draw": "1560 mW", but it was rounding up every turn. I.e. the flashlight was set to that already, but it rounded up from 1560 mJ / second to 1 kJ per second. Now it actually consunes 1560 mJ / second and lasts about 10h as stated in the related product page.

Charges_per_use along with turns_per_charge works by evaluating that fraction, but the preferred solution is power_draw.

You are correct that this does not impact initial activation, that's all entangled with the iuse infrastructure and is still limited to charges.