Various bug fixes in gdp.mbigm transformation

[emma58]

Fixes # .

Summary/Motivation:

Fixes three bugs in the multiple bigm transformation:

1. There was an indentation error that was revealed by having (active) empty constraint containers on Disjuncts. Now we only deactivate constraints that exist, wheee.
2. Not all Suffixes are bad Suffixes: Ceasing to complain when we ignore Suffixes, but adding a note to the documentation that we will ignore BigM Suffixes, since that might not be intuitive. (We're also safe that this will never change because the keys will always be different for bigm and mbigm: mbigm needs to know the Disjunct the M is relative to as well.)
3. Disjuncts can be infeasible--it's okay: When the solve to calculate M comes back infeasible, this means the Disjunct is. We log that fact at the DEBUG level, and properly deactivate the Disjunct. I'm setting the M values to 0 for now for the sake of being explicit.

Changes proposed in this PR:

• Fixes to the above
• Tests!

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (f81f34f) 88.34% compared to head (affa10c) 88.33%.
Report is 13 commits behind head on main.

Files	Patch %	Lines
pyomo/gdp/plugins/multiple_bigm.py	96.29%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3073      +/-   ##
==========================================
- Coverage   88.34%   88.33%   -0.01%     
==========================================
  Files         833      833              
  Lines       92567    92582      +15     
==========================================
+ Hits        81776    81786      +10     
- Misses      10791    10796       +5     

Flag	Coverage Δ
linux	86.23% <96.29%> (+<0.01%)	⬆️
osx	75.69% <92.59%> (+<0.01%)	⬆️
other	86.43% <96.29%> (-0.01%)	⬇️
win	83.64% <96.29%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[jsiirola]

A couple general questions

[jsiirola]

Are we sure that we want to check against "infeasible"? For the "old" (current) solver interfaces, I am not sure if this is always a guarantee of infeasibility. (In particular, I don't think that Ipopt will ever guarantee infeasibility)

[emma58]

I changed this so that we maintain a list of solvers we trust that 'infeasible' means 'proven infeasible' and we do this for those. For others (looking at you, ipopt), we just revert to the old behavior and scream about an unsuccessful solve.

[jsiirola]

Same question on infeasible here...

[jsiirola]

Are we sure we want to silently ignore Suffixes?

[emma58]

I changed this to ignore LocalVars, warn about ignoring BigM, and yell for everything else.

[emma58]

OK, @jsiirola, this is ready for another look.

[jsiirola]

I don't think we can rely on solver.name here:

>>> SolverFactory('gurobi_direct').name
'gurobi_direct'
>>> SolverFactory('gurobi_persistent').name
'gurobi_persistent'
>>> SolverFactory('gurobi', solver_io='lp').name
'gurobi'
>>> SolverFactory('gurobi', solver_io='nl').name
'asl'
>>> SolverFactory('appsi_gurobi').name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'LegacySolver' object has no attribute 'name'

If we are going to do this, maybe the solution is that the solvers advertise two new attributes: .algorithm and .interface? @mrmundt, @michaelbynum?