Fix - Upcoming arithmetic_side_effects lints

[Lichtso]

Problem

This PR is another preparation for #32961.
saturating and wrapping versions of div and rem will no longer be accepted.

Summary of Changes

Replaces them with their checked version.

[t-nelson]

i'd like to review some of the introduced unwraps here before merging

[apfitzge]

i'd like to review some of the introduced unwraps here before merging

I think the main ones that stood out to me are the ones with the compute budget. Those appear to be defined as constants initialized in ComputeBudget::new, but not entirely clear those aren't modified and set to 0.

Other unwraps involving align_of or constants should be safe as those cannot or are not 0.

[Lichtso]

I made all the divisions which have a non-constant divisor (those used in CU consumption) to be .unwrap_or(u64::MAX). Meaning that if the divisor becomes 0 the program definitely fails because it consumes all CUs.

[t-nelson]

pushed a few more commits to wrap up arithmetic_side_effects compatibility

[t-nelson]

it's annoying that the lint can't resolve non-zero literals. compiler can know this div is safe

[ilya-bobyr]

Does it generate a linter warning?
At -O it is compiled to a bit shift:

pub fn square(num: u64) -> u64 {
    num.checked_div(2).unwrap()
}

example::square:
        mov     rax, rdi
        shr     rax
        ret

https://godbolt.org/z/xz8cPjccP

[Lichtso]

I think that happens in LLVM, not in rustc. In other words, rustc is probably unaware.

[t-nelson]

was the commit that switched unwraps to expects dropped intentionally/

[t-nelson]

was the commit that switched unwraps to expects dropped intentionally/

n/m, i see that it was squashed in. more rebase hell than i was hoping for this early in the day 😅

[Lichtso]

Yes, I reordered and squashed the commits to reduce the forward / backward changes.