Fix 'Wconversion' warns: static casting doubles

[melvinhe]

*Issue number of the reported bug or feature request: #87 *

Describe your changes
This is a small good first issue contribution to fix -Wconversion warnings that pollutes the build log.

This particular PR deals with the following warnings:

/home/runner/work/blazingmq/blazingmq/src/groups/mwc/mwcu/mwcu_printutil.cpp:186:13: warning: conversion from ‘BloombergLP::bsls::Types::Int64’ {aka ‘long long int’} to ‘double’ may change value [-Wconversion]
  186 |             bytes / bsl::pow(1024., static_cast<double>(unit)));

/home/runner/work/blazingmq/blazingmq/src/groups/mwc/mwcu/mwcu_printutil.cpp:275:48: warning: conversion from ‘BloombergLP::bsls::Types::Int64’ {aka ‘long long int’} to ‘double’ may change value [-Wconversion]
  275 |         const bsls::Types::Int64 quot = lround(timeNs /

/home/runner/work/blazingmq/blazingmq/src/groups/mwc/mwcu/mwcu_printutil.cpp:284:57: warning: conversion from ‘BloombergLP::bsls::Types::Int64’ {aka ‘long long int’} to ‘double’ may change value [-Wconversion]
  284 |             (static_cast<double>(timeNs - quot * div) / div) *

Testing performed
N/A

Additional context
Converting from BloombergLP::bsls::Types::Int64 (a 64-bit integer) to double (a 64-bit floating-point) can potentially lead to a loss of precision, but it depends on the size of the integer value used in this context. The division involving another double should already result in similar loss of precision though, so this may be fine. Please check this before merging.

[pniedzielski]

🎉

@melvinhe, could you run clang-format on these changes? Everything looks good except for a failing format check on our CI.

[melvinhe]

@pniedzielski Thanks, just ran the format check with clang-format for the CI. See: Fix 'Wconversion' warns: static casting doubles #214

[pniedzielski]

@melvinhe Thanks! Formatting checks pass now, but I think you had an issue with rebasing, since you've recommitted some changes that were merged into main, which results in merge conflicts when we try to merge this PR. Can you make sure your branch contains only a single commit, squashing your two patches into just one, and not including commits 83c1293, 6f99cd4, and
1f8f881?

If you're not confident with these git operations, I can walk you through it.

[melvinhe]

@pniedzielski Sure, after seeing the 3 recent commits added recently, I updated my forked repo main branch to be up to date with bloomberg/blazingmq:main.

Since my old 'wconversion_fix' branch was causing issues when merging, I created a new 'wconv_fix' branch from my local main, manually made my previous casting and formatting edits, and pushed & made a new PR. I realize now that this may be more of a roundabout way of doing things, but the new PR seems to be passing all the Tests other than the integration test that a different commit broke: #214

Should I just deal with the 'wconv_fix' branch than and get rid of my old 'wconversion_fix' branch? Or how else should I remedy this. Thanks!

[pniedzielski]

@melvinhe We'll work on #214, no worries.