Add mps/gz support

[dthuerck]

What should we add?

What should we add?

Most collections of optimization models use the old-fashioned MPS format for model storage, e.g., MIPLIB. Furthermore, due to their verbosity (compare, e.g., square47.mps.gz wit squaren47.mps from MIPLIB - 80 MB vs. 1.4GB) people tend to use the gzipped files directly.

If qiskit optimization serves as gateway to classical and quantum optimization, I think it makes perfect sense to include this widely-adopted file format. docplex supports mps natively.

[t-imamichi]

Users can import and export docplex models via from_docplex_mp and to_docplex_mp. So, I think they can handle MPS format through docplex model. We carefully think of adding new public methods to QuadraticProgram because it increases the maintenance cost.

[t-imamichi]

As commented in https://github.com/qiskit-community/qiskit-optimization/pull/581#issuecomment-1851326579, I personally suggest making functions in qiskit_optimizatiopn.translators.

[dthuerck]

Sure, we can move it there @t-imamichi . In this case, I'd vote that we also move all lp-related functions (as you suggested in the PR).

Since this breaks the QuadraticProgram, we could add a deprecation warning and in the meantime, forward to the functions in translator. What do you think?

[woodsp-ibm]

we could add a deprecation warning and in the meantime, forward to the functions in translator. What do you think?

For breaking API changes maintaining compatibility via deprecation, which informs the replacement (or whatever) to maintain users code working and give them a chance to change, is definitely the way to go. Works for me.

The deprecation would also be noted in a release note deprecations section as part of the PR so it becomes part of the compete release notes in end-user docs. Since the PR is also adding new features these should be listed there in the features section of the same note (other unused sections would be simply deleted from the note as creation creates one with all sections present).

As the move will involve a few test files that use the logic having the move/deprecation done as a separate PR could also be a choice.

[dthuerck]

@woodsp-ibm Sounds good. I'll proceed then as follows:

1. Create a PR using the move/deprecate logic for current stuff inside QuadraticProgram that goes into, e.g., translators.
2. After that has been merged, I'll adapt this PR here accordingly to the new structure.