optimize-relinearization: Remove requirement that arguments have equal key-basis degrees

[j2kun]

This PR modifies the ILP for optimize-relinearization to permit the possibility that the operands to an op like arith.addi have mixed key-basis degrees. E.g., you can add a ciphertext with basis (1, s) to another with basis (1, s, s^2).

Based on the discussion in #1284, Lattigo and OpenFHE both support this for BGV.

To hedge against the possibility a future backend does not support this, I made the relaxation optional via a new pass option (allow-mixed-level-ops).

The impact of this relaxation on the ILP is not as trivial as I had hoped. When removing the constraints on key basis degree for operands, I had to add new constraints that the output degree is at least as big as each input degree. Ideally this comes paired with an objective term that makes the output degree as small as possible, which would implement a result_degree = max(arg0_degree, ..., argN_degree) function. However, adding this to the objective causes the solver to "cheat" by inserting relinearization terms earlier than necessary to as to reduce cost of the new terms.

The "right" solution here is to properly cost model the solver's choices (#1018). Instead of minimizing the total number of relin ops, have a cost for each op at each level, as well as the cost of doing a relin op from each starting level.

In the interim, we simply ignore the fact that the solver may assign a larger key-basis-degree for the output of an add op than necessary. It doesn't seem to affect the correctness of any results; hallucinating larger key-basis degree doesn't change whether or not you need to relinearize, just the mechanics of how to relinearize, which is handled opaquely by the backend anyway. In particular, if the output degree of an op were truly 1, but the solver decided to make it 2, this would require inserting a relin op when it's not necessary, so the solver naturally avoids this situation. But if the degree were 2 and the solver hallucinated it should be 3, we still relin.

Fixes #1284

[ZenithalHourlyRate]

also remember to update the relinearization_ilp.md.

[j2kun]

Updated the doc as well

[ZenithalHourlyRate]

For relinearization_ilp.md there is one more place mentioning the same degree requirement, i.e.

Addition can operate in any key basis (though all inputs must have the same key basis),

[AlexanderViand-Intel]

This PR modifies the ILP for optimize-relinearization to permit the possibility that the operands to an op like arith.addi have mixed key-basis degrees. E.g., you can add a ciphertext with basis (1, s) to another with basis (1, s, s^2).

Based on the discussion in #1284, Lattigo and OpenFHE both support this for BGV.

To hedge against the possibility a future backend does not support this, I made the relaxation optional via a new pass option (allow-mixed-level-ops).

I think the main issue here is for CKKS and the GHS variant of BGV, where the messages are scaled. In those settings, we can't just do $(c_0, c_1) + (c'_0, c'_1, c'_2) = (c_0 + c'_0, c_1 + c'_1, c'_2)$ (as we can, afaik, in traditional BGV and in BFV), because the message in ctxt c will be scaled by a different factor than that in ctxt c'. While being able to toggle mixed operations off is good, I think it's not actually sufficient to prevent similar scaling-related issues all the time.

So maybe we don't even need the toggle, but just a solution to #1169 (tracking the message scale) + making the modswitch mgmt aware of the need to adjust the scales?

[j2kun]

Squashed and marking pull_ready