**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!

{
    return parseWithSizeSuffix<T>(data, strlen(data));
}
template <typename T>
inline T parse(const char * data)
{
    return parse<T>(data, strlen(data));
}
template <typename T>
inline T parse(const String & s)
{
    return parse<T>(s.data(), s.size());
}
template <typename T>
inline bool tryParse(T & res, const char * data)
{
    return tryParse(res, data, strlen(data));
}
template <typename T>
inline bool tryParse(T & res, const String & s)
{
    return tryParse(res, s.data(), s.size());
}
/** Skip UTF-8 BOM if it is under cursor.
  * As BOM is usually located at start of stream, and buffer size is usually larger than three bytes,
  *  the function expects, that all three bytes of BOM is fully in buffer (otherwise it don't skip anything).
  */
inline void skipBOMIfExists(ReadBuffer & buf)