**Describe the bug**
When using the HTTP protocol with DateTime64 types, numerical timestamps in milliseconds do not parse correctly. This is an issue when using the Clickhouse JDBC driver with Avro Kafka records because the timestamps are integers. 

**How to reproduce**
I'm using the following CH version: yandex/clickhouse-server:20.4.5.36

Create a sample table with: 
```sql
create table tst(ts DateTime64(3)) engine TinyLog();
```

Attempt to insert millisecond timestamp into the column:
```bash
echo "1596215121682" | http -v :8123 query=="insert into tst format TSV"
```

Error:
```bash
Code: 27, e.displayText() = DB::Exception: Cannot parse input: expected '\n' before: '682\n': (at row 1)

Row 1:
Column 0,   name: ts, type: DateTime64(3), parsed text: "1596215121"
ERROR: garbage after DateTime64(3): "682<LINE FEED>"

 (version 20.4.5.36 (official build))
```

Oddly, specifying a raw query, this works:
```bash
echo 'insert into tst values(1596215121682)' | curl 'http://localhost:8123/' --data-binary @-
```
Result:
```bash
SELECT *
FROM tst

┌──────────────────────ts─┐
│ 2020-07-31 17:05:21.682 │
└─────────────────────────┘
```



**Expected behavior**
I expect to be able to insert integer millisecond timestamps using the HTTP batch insert protocol. 

Again, this issue is preventing us from using the Clickhouse JDBC driver because it fails to parse our Avro records from Kafka.

Appreciate the help!

{
    if (!buf.eof()
        && buf.position() + 3 < buf.buffer().end()
        && buf.position()[0] == '\xEF'
        && buf.position()[1] == '\xBB'
        && buf.position()[2] == '\xBF')
    {
        buf.position() += 3;
    }
}
void skipToNextLineOrEOF(ReadBuffer & buf);
void skipToCarriageReturnOrEOF(ReadBuffer & buf);
void skipToUnescapedNextLineOrEOF(ReadBuffer & buf);
/** This function just copies the data from buffer's internal position (in.position())
  * to current position (from arguments) into memory.
  */
void saveUpToPosition(ReadBuffer & in, Memory<> & memory, char * current);
/** This function is negative to eof().
  * In fact it returns whether the data was loaded to internal ReadBuffers's buffer or not.
  * And saves data from buffer's position to current if there is no pending data in buffer.
  * Why we have to use this strange function? Consider we have buffer's internal position in the middle
  * of our buffer and the current cursor in the end of the buffer. When we call eof() it calls next().
  * And this function can fill the buffer with new data, so we will lose the data from previous buffer state.
  */
bool loadAtPosition(ReadBuffer & in, Memory<> & memory, char * & current);
struct PcgDeserializer
{
    static void deserializePcg32(const pcg32_fast & rng, ReadBuffer & buf)