In cube.intersection, find split cells using a tolerant equality check

[lbdreyer]

When performing a cube.intersection, Iris sometimes has to wrap the coord bounds. As an example when the coord on the original cube is between (0,360), but someone requests an intersection of (-60, 60). This can result in split cells that straddle the wrap point. For example, your original bounds may be:

array([[299.7, 299.8],
       [299.8, 299.9],
       [299.9, 300. ],
       [300. , 300.1],
       [300.1, 300.2]])

But your wrapped bounds, with wrapping point of -60, will look like:

array([[299.7, 299.8],
       [299.8, 299.9],
       [299.9, -60. ], # straddle point!
       [-60. , -59.9],
       [-59.9, -59.8]])

Iris calculates the diff between the upper and lower bounds, for bounds inside the requested intersection, resulting in the variables pre_wrap_delta and post_wrap_delta, and then it compares these to find any straddle points.
If there are any differences, it will then use these to determine where the new wrapping point (which avoids the straddle points) should be.

Notably, Iris first checks whether there are any diffs between pre_wrap_delta and post_wrap_delta with np.allclose(). If there are differences, it then determines where they are. This np.allclose check was introduced in #1641 as we had found previous issues with numerical tolerances (post_wrap_delta was almost like pre_wrap_delta).
However, if np.allclose returns False as there is a definite straddle point, in order to find where the straddle points are Iris uses np.where(pre_wrap_delta!= post_wrap_delta). But this again causes problems with numerical tolerances, and so when Iris tries to work out where the new wrapping point should be, it gets this wrong.

I've outlined an example below :

Using the bounds and wrapped bounds we have above, the pre_wrap_delta looks like:

array([[0.1],
        [0.1],
        [0.1],
        [0.1]]),

(note the intersections doesn't include the first cell (299.8,299.9) as that is outside our intersection area of (-60, 60)
and the post_wrap_delta looks like

array([[ 1.000e-01],
       [-3.599e+02],
       [ 1.000e-01],
       [ 1.000e-01]])

Those almost match but not quite:

>>> pre_wrap_delta != post_wrap_delta
array([[ True],
       [ True],
       [ True],
       [ True]])
>>> pre_wrap_delta[-1][0]
0.0999999999999659
>>> post_wrap_delta[-1][0]
0.10000000000000142

So Iris thinks they are all straddle points, and so ends up choosing a wrong new wrap point.

This PR changes the search for straddle points to instead use a tolerant equality check:

split_cell_indices, _ = np.where(
                    ~np.isclose(pre_wrap_delta, post_wrap_delta)
                )

Which allows for these floating point problems.

[rcomer]

So the logic introduced at #4059 assumed there would be only one split cell, and that split cell would be around the requested minimum. This PR ensures that that assumption is valid, so looks right to me.

Looking at this again makes me realise #4059 should have been slightly different though. If the check had used maximum - modulus instead of maximum % modulus, the recalculation would have happened, since -300 is not in cells. I've opened #4221 to follow up on that at some point (I don't think it's urgent).

[bjlittle]

I'd forgotten just how much Cube.intersection hurts my head 🤯

Awesome fix 🚀 💯

Just a couple of minor changes to bolster the tests and I think we're there 👍

[lbdreyer]

Docs are broken 😩
I'll try fixing tomorrow morning!

[bjlittle]

@lbdreyer Awesome. Just some minor changes to the whatsnew. I think my suggestions should fix the docs building.

Also, could you:

• add a reference to the 3.0.3.rst at the top of the docs/iris/src/whatsnew/index.rst
• bump the iris.__version__ to be 3.0.3 (might as well do this now 👍)

[bjlittle]

@lbdreyer Fantastic, thanks 🍻