remove part that determines how many bytes are needed since CRC32 alw…

[agostain]

remove part that determines how many bytes are needed since CRC32 always has 4-byte hash; that calculated wrong crc32 for some object parts.

Issue #, if available:

When performing a mulitpart upload the the get-object-attributes cli command provides the following output:

{
    "LastModified": "2024-12-09T16:14:11+00:00",
    "Checksum": {
        "ChecksumCRC32": "lMiKhQ=="
    },
    "ObjectParts": {
        "TotalPartsCount": 5,
        "PartNumberMarker": 0,
        "NextPartNumberMarker": 5,
        "MaxParts": 1000,
        "IsTruncated": false,
        "Parts": [
            {
                "PartNumber": 1,
                "Size": 20971520,
                "ChecksumCRC32": "/HahzA=="
            },
            {
                "PartNumber": 2,
                "Size": 20971520,
                "ChecksumCRC32": "HrlK1A=="
            },
            {
                "PartNumber": 3,
                "Size": 20971520,
                "ChecksumCRC32": "bIrofQ=="
            },
            {
                "PartNumber": 4,
                "Size": 20971520,
                "ChecksumCRC32": "ANviCQ=="
            },
            {
                "PartNumber": 5,
                "Size": 20971520,
                "ChecksumCRC32": "CgbEDA=="
            }
        ]
    }
}

The checksums for each object part calculated by checksum verification tool:

b'/HahzA=='
b'HrlK1A=='
b'bIrofQ=='
b'2+IJ'
b'CgbEDA=='
FAIL: ChecksumCRC32 DO NOT MATCH!

The last two checksums are wrongly calculated.

Description of changes:

The issue in the original code was that m.bit_length() could vary, leading to inconsistent byte lengths. CRC32 should always be represented as 4 bytes. The change fixes the false positive.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.