need to switch `ShareAccounting` work representation from `f64` to `u64` on `channels_sv2`

[plebhash]

when channels_sv2 was originally written, I took some inspiration from Braiins UI, which represents work as floating point numbers

I also remember contemplating the fact that strictly speaking, work is a unit of difficulty, and therefore it can (and should) be tracked as floating point numbers (like rust bitcoin does)

this is specially true when we're operating at diff ranges 0 < diff < 1, where we have no relevant data unless we're working with floating point numbers

but as we noted on #2090 (comment), this was kind of a failed attempt at retaining granular data, because SubmitSharesSuccess.new_shares_sum is U64, which forces everyone to truncate and makes an internal representation based on f64 pretty much useless

[plebhash]

for the client side, everything is going to arrive over the wire as u64, so indeed there's no point in representing work as f64

but on the server side, if we truncated every share's work into u64 before it was stored on memory, repeated truncation would cause the work accounting to drift away from its real value over time

so on the server side, it's sufficient to keep truncation limited to get_last_batch_work_sum (which is the getter used for crafting SubmitSharesSuccess), while maintaing f64 for in-memory representation of work

therefore the scope here is actually somewhat narrower than originally described

[plebhash]

tbh this issue is making me think a bit about auditability

the rationale behind this change is the fact that client::ShareAccounting::share_work_sum tracks whatever Pool is sending via SubmitShares.Success.new_shares_sum, which is U64

but what if Pool is cheating? we're already validating shares on the client side, why not keep track of their work for auditability purposes?

shouldn't we have something like this?

pub struct ShareAccounting {
    last_share_sequence_number: u32,
    acknowledged_shares: u32,
+   acknowledged_work_sum: u64,
    validated_shares: u32,
+   validated_work_sum: f64,
    rejected_shares: u32,
-   share_work_sum: f64,
    seen_shares: HashSet<Hash>,
    best_diff: f64,
    blocks_found: u32,
}

then the only differences between acknowledged_work_sum vs validated_work_sum should be:

• u64 vs f64 truncation
• rejected shares
• not-yet-acknowledged shares from the current/last batch

anything that breaks these invariants should be treated as an auditability error