Describe the bug

According to the docs, a long is a "Signed integer 0x8000000000000000L to 0x7fffffffffffffffL".

We have a value that happens to be Long.MIN_VALUE that we would like to record in questdb, but inserting it over the line protocol gets the following error recorded in the server logs:

2023-02-22T10:50:58.020358Z E i.q.c.l.t.LineTcpConnectionContext [24] could not parse measurement, INVALID_FIELD_VALUE at 26, line (may be mangled due to partial parsing): 'long_col_only big_boy=NaNi'

We have seen that Long.MIN_VALUE is special cased to NaN in the line protocol, but don't see why this was done if the server side cannot handle this?

To reproduce

1. Create a table with a long column

CREATE TABLE long_col_only (
  big_boy LONG
);

2. Attempt to insert Long.MIN_VALUE over the line protocol

    public static void main(String[] args)
    {
        try (Sender sender = Sender.builder().address("localhost:9009").build())
        {
            sender.table("long_col_only")
                    .longColumn("big_boy", Long.MIN_VALUE)
                    .atNow();
        }
    }

Expected Behavior

SELECT * FROM 'long_col_only';

Should return a row with the value being either 0x8000000000000000 or null (as mentioned in the docs)

Environment

- **QuestDB version**: 7.0.0 (jdk11)
- **OS**: Fedora 36
- **Browser**: Firefox 100.0 (64-bit)

Additional context

No response