Matmul warning

[rileyjmurray]

This addresses #1238 and is intended to supersede #1239. It removes side-effects of our existing warnings for accessing matmul through * and introduces a new MatmulWarning class for that purpose.

This PR also updates the web doc source to mention the importance of cvxpy 1.1.10 for the numpy installation issue.

[akshayka]

I think raising a MatmulWarning instead of a DeprecationWarning is bit odd. Production could might have policies that promote DeprecationWarning's to errors. A custom MatmulWarning will go undetected, unless a human sees it.

Why not raise a DeprecationWarning, which is a very standard type of warning? Humans will understand it, and so will codebases. Its semantics are very clear.

[akshayka]

That said I don't feel strongly, so I won't block this! I'll leave it to @SteveDiamond to make the call

[rileyjmurray]

We changed from a DeprecationWarning to a UserWarning a while back, because DeprecationWarnings are not as visible to users: https://github.com/cvxgrp/cvxpy/issues/980 and https://github.com/cvxgrp/cvxpy/pull/981.

I see your point about the semantics of DeprecationWarning though. One option would be to raise a DeprecationWarning in addition to something a user is more likely to see. I'd be okay with removing the custom MatmulWarning if we raised both a DeprecationWarning and UserWarning. I think both are actually justified, as the DeprecationWarning says "you should change this code and may have to change code elsewhere to be compliant in the future", while a UserWarning says "this might not have done what you thought it was going to do."

@akshayka what do you think about the two-warning option?

[akshayka]

@rileyjmurray , that sounds good to me!

[SteveDiamond]

I'm also fine with the two warnings.

[rileyjmurray]

Great! I'll change it to two warnings and merge it in later today.