I think we ignore the point entirely for CLOSEPOLY, but what happens for something like?

p = Path(
    [[0, 0], [np.nan, np.nan]],
    [1, 79])

what happens for something like?

p = Path(
    [[0, 0], [np.nan, np.nan]],
    [1, 79])

Great question. It leaves it as-is. (Same as previous behavior).

>>> p.cleaned(remove_nans=True)
Path(array([[ 0.,  0.],
       [nan, nan],
       [ 0.,  0.]]), array([ 1, 79,  0], dtype=uint8))

I think this makes sense because

1. We document that the vertex attached to the CLOSEPOLY command is ignored, and
2. We were already leaving all CLOSEPOLY's in before, including these NaN ones

So this PR only changes the behavior when leaving a CLOSEPOLY in would result in an ill-defined Path.

I'm aware that this doesn't play well with PathSimplifier:

>>> p.cleaned(remove_nans=True, simplify=True)
Path(array([[ 0.,  0.],
       [nan, nan],
       [nan, nan],
       [ 0.,  0.]]), array([1, 2, 2, 0], dtype=uint8))

but this is also existing behavior, and I haven't taken the time to grok the full PathSimplifer algorithm yet to know whether or not it's easy to do even better.

Per the call, added tests that check the "optimized" code path (i.e. empty codes array) and explicitly added the breaking example from #17868 as a test case.