Add support for knapsack constraints

[Joao-Dionisio]

Fix #941

Still not done, but this is pretty fun, in a turn off your brain and code kind of way.

Currently having some problems with the compilation, but likely due to my local SCIP, will re-check later.

[Copilot]

Pull Request Overview

This PR adds support for knapsack constraints by allowing an optional flag in addCons, and updates tests to validate the new functionality.

• Introduces a new test function for knapsack constraints in tests/test_cons.py
• Modifies tests for linear constraint coefficient retrieval in tests/test_cons.py
• Updates CHANGELOG.md to document the new knapsack constraint support

Reviewed Changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/test_cons.py	Added tests for knapsack constraint flag and related methods
CHANGELOG.md	Updated changelog to include knapsack constraint support

Files not reviewed (2)

• src/pyscipopt/scip.pxd: Language not supported
• src/pyscipopt/scip.pxi: Language not supported

Comments suppressed due to low confidence (2)

tests/test_cons.py:225

• Consider adding negative test cases for constraints without the knapsack flag to verify that knapsack-specific methods are not available in non-knapsack constraints.

knapsack_cons = m.addCons(4*x + 2*y <= 10, knapsack=True)

tests/test_cons.py:251

• Clarify and assert the expected coefficient order from getValsLinear to ensure consistency, especially if constraint transformations occur during optimization.

assert m.getValsLinear(c1) == [2,1]

[Joao-Dionisio]

Updated the default values of the logical constraint names, because they would cause issues (like the one that happened with the indicator constraints - can't find the issue atm)

[DominikKamp]

Values are SCIP_Longint, not SCIP_Real, and should accept Python int.

[DominikKamp]

Can someone tell copilot that pxi and pxd is Python?

[Joao-Dionisio]

Thank you, @DominikKamp! By the way, how do you feel about the default names for indicator and logical constraints? Ie, if you add 1 AND constraint and two OR constraints without naming them, they default to "c1AND", "c2OR", "c3OR".

Also, should we try to lump all the methods together? For example, should getRhs work with every handler, or should we really just have a getRhsLinear (but without changing the name), getKnapsackCapacity, etc.?

And finally, yeah Copilot is still a bit dummy, unfortunately. Maybe next year :)

[DominikKamp]

If there is a common counter for constraints, it should not be necessary to add the constraint type to the name if there is a way to get the name of the constraint handler separately (without it, this is also more like the generic names in SCIP).

Yes, there should be wrappers for SCIPconsGet...() but some special constraints require additional methods like for knapsack to get the integral values.