BUG #18214: poly_contain (@>) hangs forever for input data with zeros and infinities

The following bug has been logged on the website:

Bug reference: 18214
Logged by: Nikolay Shaplov
Email address: dhyan(at)nataraj(dot)su
PostgreSQL version: 16.1
Operating system: Debian 12
Description:

In postgreses 14-16, you execute following query it will work "forever"

select '((-inf, 0), (0, inf), (-inf, 0), (0, inf), (0, 0), (0, 0), (0, 0),
(0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
(0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0))'::polygon @> '((0, 0), (0, 0),
(0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
(0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
(-inf, 0))'::polygon;

(Colleges says it is o(n!), it worked for me for 24h and then I stopped
it)

This bug have been found while fuzzing @> operation using AFL++ as Fuzzer
Engine and LibBlobStamper for Structure Aware Fuzzing

Removing items from the query makes it work "faster" (e.g. several hours).

My colleagues have poked this bug a bit, and suggested that the cause of the
problem is probably the lseg_contain_point(LSEG *lseg, Point *pt) function,
that gives wrong result for the infinity case. Like lseg = {(0, 0), ( -inf,
0)} and pt = (0, inf) does not contain one another, but lseg_contain_point
gives true for that data.

Also they gave another example:

select '((inf, 0), (0, -inf), (0, 0))'::polygon @> '((0, 0), (inf,
0))'::polygon a;
a |
-----+
false|

select '((-inf, 0), (0, inf),(0, 0))'::polygon @> '((0, 0), (-inf,
0))'::polygon a;
a |
----+
true|

If you just mirror sign of infinity, you get different result (and it should
be the same since geometry have not been changed, just have been mirrored)

PS I will provide raw data that came from Fuzzier attached to the next
message, since I can not attach it in the