Fix issue 2786

[fwesselm]

• Count number of bound changes instead of checking for change in objective lower bound in HighsDomain::ObjectivePropagation::propagate (which should fix the stall reported in HiGHS Infinite Loop 32 bit RelWithDebInfo #2786).
• Added utility HighsDomain::checkChangeBound to simplify the code.
• Testing showed that the code change does not affect behavior very much. The new code is slightly faster and computes less nodes (time ratio is 0.98 and node ratio 0.99), but this may just be a random effect.

[codecov]

Codecov Report

❌ Patch coverage is 96.42857% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.33%. Comparing base (28a9e28) to head (946a7bb).
⚠️ Report is 6 commits behind head on latest.

Files with missing lines	Patch %	Lines
highs/mip/HighsDomain.cpp	96.42%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           latest    #2807   +/-   ##
=======================================
  Coverage   80.32%   80.33%           
=======================================
  Files         348      348           
  Lines       86093    86084    -9     
=======================================
- Hits        69157    69152    -5     
+ Misses      16936    16932    -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Opt-Mucca]

Code looks good! I'm a big fan of the new function and checking the number of bounds vs comparing the objective value directly.
Are the affected instances happening because new bound changes can now be made in a second round, i.e., the objective doesn't change when x_j was updated and the old code would've stopped but the new change allows you to change x_i in the next round of the loop? Or is the code just different and I'm missing something?

[fwesselm]

Code looks good! I'm a big fan of the new function and checking the number of bounds vs comparing the objective value directly. Are the affected instances happening because new bound changes can now be made in a second round, i.e., the objective doesn't change when x_j was updated and the old code would've stopped but the new change allows you to change x_i in the next round of the loop? Or is the code just different and I'm missing something?

Thanks, @Opt-Mucca. Yes, I think this is what is happening. For example, on stein45 the new code finds additional bound changes although objectiveLower does not change.