Fix set max_rd_atomic respecting the local device limit

[sfff]

When configuring max_rd_atomic account for our device's constraint in cases where the destination's max_qp_rd_atom (from ibv_devinfo -v) exceeds our local limit.

[sshaulnv]

@sfff, Thanks for the PR.
The change looks great, except the fact that the it will print report with the original outstanding reads.
please fix the report print and we can have it merged.

[sfff]

@sshaulnv, Thank you for the review and the improvement suggestion. I agree that the current approach may appear somewhat complex.
That said, the existing output scheme, although not very simple, already provides all the required information:

1. The test header displays the current parameters print user_param->out_reads
2. After exchanging information with the remote side, the output includes details about Outstand reads on both the local (local address: LID 0000 QPN ... OUT ...) and remote sides (remote address: LID 0000 QPN ... OUT ...) print remote OUT

Would it make sense to rename "OUT %#04x" to "OUTSTAND %#04x"? Alternatively, is there a better way to improve the clarity of the output without breaking the established convention?

I would like to additionally point out that this patch is intended to prevent an error in cases where the local value (printed in test header) is lower than the value obtained from the remote side.

[sfff]

I would like to clarify why I think keeping the current output format unchanged is the least intrusive option for this fix.

The header prints the local requested/configured test parameters. In contrast, the local address: / remote address: lines print the exchanged endpoint data. For tests, OUT is part of that exchanged endpoint information, not a separate report of the final QP state.

With this patch, the value programmed into max_rd_atomic is derived from the two already printed exchanged values:

effective max_rd_atomic = min(local OUT, remote OUT)

Adding this value into the existing address line would mix two different meanings in one line: endpoint exchange data and negotiated QP configuration. It would also change an established compact output format that may already be consumed by scripts/parsers.

For that reason, I would prefer to keep this patch limited to the functional fix and avoid changing the output format unless you strongly prefer an explicit additional line.

@sshaulnv Does this explanation address your concern about the report output, or would you still prefer a follow-up output change before merge?