Replace deprecated scipy.integrate.quadrature in the TestLineShapes

[vsnever]

This PR replaces deprecated scipy.integrate.quadrature with Cherab's own GaussianQuadrature integration method in the TestLineShapes test case.

[jacklovell]

My worry here is that the lineshape test now depends on GaussianQuadrature functionality so is getting closer to an integration test than a unit test. OK, we do at least have test coverage of GaussianQuadrature but personally I would prefer to use a thoroughly tested scipy function rather than another Cherab utility to isolate the lineshape from the integration tests.

Having done a bit more research, it appears scipy.integrate.quad is genuinely a better solution than scipy.integrate.quadrature, not just a rename as I initially thought, so I'd suggest swapping to scipy.integrate.quad instead. It's been available for ages (since at least 0.13, possibly earlier) so there's no worries about backwards compatibility with old Python/Scipy versions.

[Mateasek]

I agree with with @jacklovell here.

The test cases for us pose as some kind of standards to be matched. This is why they should be analytical solutions where possible. Where not possible, the tests should be constructed with widely accepted external libraries. Then, the tests warn us if any new code causes discrepancies out of set tolerances. Performing tests with "in-house" functionality increases probability of missing a problem

For example, if there is a PR which introduces changes to the GaussianQuadrature which in turn causes discrepancies with line shape standards in this case, the proposed changes would cause the test to completely miss it and that is in my opinion wrong.

For these reasons, I would suggest using scipy functionality (as suggested by @jacklovell ) because it is tested by a wider user pool, can be assumed as a kind of standard here and is not "in-house".

[vsnever]

I agree. When we use a scipy function, we are testing both the line shape model and the integration itself, and it's better. I replaced quadrature() with quad().

GaussianQuadrature is based on scipy's quadrature() algorithm, so they give identical results no matter what the relative tolerance is set to, as long as it is the same for both. The quad() algorithm is slightly different, so we should now compare results within the tolerance threshold only.

[Mateasek]

Thanks for updating the tests to use the quad function. I have one minor suggestion which I didn't catch last time.

[Mateasek]

1.e-8 is used in the quad calls too, please consider using a variable instead (e.g. relative_tolerance), if the values are supposed to be equal here and below. It could save some trouble in the future.

[vsnever]

Thanks, @Mateasek. I added the relative_tolerance variable. Also, in this case it is better to check for relative error rather than absolute error, so I changed that too.