bank_table: need clarification on constraints with shares about flux-accounting

[ryanday36]

With fair tree, all of the comparisons are between banks that are at the same level, so sum(child_shares) does not need to be constrained by parent_shares. We do have a common use case where we explicitly make sum(child_shares) >> parent_shares. When an LDRD or other grant period ends, we'll often take all of the banks from that grant period and put them under an 'expired' parent bank with 1 share as a way to gently transition the old projects off, but still allow them to run if the new projects take a bit of time to get spun up.

I don't recall if there was such a constraint with the fair share algorithm that we used prior to fairtree, but it could probably be worked around by normalizing in the fair share calculations if necessary.

[dongahn]

This tells me we need a clear definition of the concept of "share" before going into the design of fairness algorithms.

It seems "share" in the context of fair tree algorithm is defined in relative terms -- relative to the share of the parent. But It may not be so for fair share or other fairness calculation algorithms. So what's valid can only be determined by the fairness plugin? Depending on what fairness algorithm we will instantiate, we expect different properties with respect to how one should interpret a "share".

Since it feels like the entered "share" can only be checked and validated at the fairness calculation logic, the subcommand like "add-bank" and "edit" should call into the fairness plugin to do this validation.

Since we don't have the fairness plugin, it appears there isn't so much we can do here yet. We should pin this and circle back to do "fairness plugin-assisted validation" once we have a test plugin.

The current PR should do minimal validation if any, though.