mmaprototype: small cleanup related to negative adjusted loads

[sumeerbhola]

Epic: CRDB-55052

Release note: None

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[tbg]

I don't love that we're making these changes without accompanying unit tests, but I understand the time commitment that backfilling this would take. Something that's on my mind and that should get better as I continue my crusade of breaking things up into smaller functions.

I will send a follow-up (that I stacked on top of this PR) to distinguish between signed and unsigned load values and to use package boundaries to make sure values that could become negative are never left unhandled.

bors r+

@tbg reviewed all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @wenyihu6)

---

-- commits line 2 at r1:
What keeps us from preventing nodes to become negative in the first place? That strikes me as more structurally sound. In this PR, the TODOs are gone and there are some places that handle negative load, but it's now a cognitive burden carried around everywhere, not to mention the realistic potential for this to regress.
If we clamp the load at zero, we lose the fact that load adding is just pure arithmetic. It won't be true, for example, that a + b - b equals a. I assume this is going to be annoying in other places. I will assume that you had considered that option too, but discarded it on those grounds.

One way we can do better with current approach: we add a type SignedLoadVector which is allowed to be negative and use that for adjusted. Then we have a method Nonnegative() or Clamp() or whatever that returns a LoadVector (=unsigned load vector) - and we make sure that is what we use whenever we

[craig]

Build succeeded:

• examples_orms
• lint
• linux_amd64_build
• unit_tests
• local_roachtest
• docker_image_amd64
• acceptance
• local_roachtest_fips
• linux_amd64_fips_build
• check_generated_code

[sumeerbhola]

Reviewable status: complete! 1 of 0 LGTMs obtained

---

-- commits line 2 at r1:

If we clamp the load at zero, we lose the fact that load adding is just pure arithmetic. It won't be true, for example, that a + b - b equals a. I assume this is going to be annoying in other places. I will assume that you had considered that option too, but discarded it on those grounds.

Exactly. We need reversible computation.

One way we can do better with current approach: we add a type SignedLoadVector which is allowed to be negative and use that for adjusted.

Sounds good to me.