Fix Buffer::bit_slice losing length with byte-aligned offsets

[itsjunetime]

Which issue does this PR close?

A part of #3478; necessary for #6690, which closes the aforementioned issue.

Rationale for this change

If bit_slice is called with a given length, the returned buffer should have the specified length.

What changes are included in this PR?

The bit_slice function itself is updated with the fix, along with a unit test to ensure the fix works. I've ensured the test fails without my changes.

I also changed the 'minimum overhead' value in an encoding test that went down due to this change.

This also updates the MSRV of this crate in Cargo.toml to 1.75, as that was (and still is, with this PR) the effective MSRV of these crates (as found by cargo-msrv). This was necessary since I wanted to use usize::div_ceil, and that was stabilized in 1.73, but clippy was complaining that I couldn't use it since the crate's msrv was 1.62.

Are there any user-facing changes?

Yes, a bug fix that could change user behavior.

[itsjunetime]

Ah, it looks like cargo msrv find tries to find the minimum available version that would work for all the crates in your workspace, including e.g. the parquet bin target and its clap dependency. I'll fix that and use bit_util::ceil instead.

[tustvold]

I'm not sure about the MSRV changes, especially to object_store which is a separate workspace entirely, but the buffer change looks good

[tustvold]

Why this change?

[itsjunetime]

I made this change because that is the effective MSRV of the majority of the crates in this workspace. It was outdated and when I disabled rust-version requirements and ran cargo msrv find in each of the crates in this repo, these were the values I found.

I know it's not directly related to what this PR was intended for, but since it tripped me up when I tried to use something outside the MRSV, I figured it was worth the time to go through each crate and make sure the MSRVs are actually accurate.

[alamb]

I am sorry for being dense but I still don't understand this change

I made this change because that is the effective MSRV of the majority of the crates in this workspace. It was outdated and when I disabled rust-version requirements and ran cargo msrv find in each of the crates in this repo, these were the values I found.

Since the msrv CI check is passing on main

https://github.com/apache/arrow-rs/actions/runs/11862785735/job/33062922708

Does that mean the CI check is not running accurately?

[alamb]

Thanks @itsjunetime -- the code in this PR looks good to me, but I am not at all sure about the MSRV changes

I am feeling quite bad about the amount of time it takes to review these PRs. It would really help I think to try and keep them as focused as possible so each PR / review had a single set of changes so that if we get hung up on / have issues with one change (e.g. the MSRV) we don't also delay the rest of the PR getting in

[alamb]

This seems to have been added as part of #5385

[alamb]

I am sorry for being dense but I still don't understand this change

I made this change because that is the effective MSRV of the majority of the crates in this workspace. It was outdated and when I disabled rust-version requirements and ran cargo msrv find in each of the crates in this repo, these were the values I found.

Since the msrv CI check is passing on main

https://github.com/apache/arrow-rs/actions/runs/11862785735/job/33062922708

Does that mean the CI check is not running accurately?

[itsjunetime]

I've removed the MSRV changes - I thought that was going to be a simple change initially, then it ended up branching out to a lot of other things. I'm going to make a separate issue and PR here to fix that specifically.

[alamb]

Thank you @itsjunetime -- this makes sense to me