Unsigned long field mapping behaviour is inconsistent with other numeric fields

[stevejgordon]

Elasticsearch version: 7.11.0
Plugins installed: []
JVM version: n/a
OS version: n/a

Description of the problem including expected versus actual behavior:
There is a discrepancy for unsigned_long vs. other numeric fields when providing a null_value in the mapping. Currently, integer for example, accepts a null_value of 1.0 which is checked for empty fractal parts. It will correctly reject a null value of 1.5. unsigned_long mappings return a "mapper_parsing_exception" when 1.0 is specified.

Ideally, the unsigned_long field should behave in the same way as other numeric fields and check for empty fractal parts.

Steps to reproduce:

1. Attempt to create an index with the following mapping

PUT my_index
{
  "mappings": {
    "properties": {
      "my_counter": {
        "type": "unsigned_long",
        "null_value": 1.0
      },
      "my_int": {
        "type": "integer",
        "null_value": 1.0
      },
      "my_short": {
        "type": "short",
        "null_value": 1.0
      }
    }
  }
}

2. Only the my_counter field causes a "mapper_parsing_exception".

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[romseygeek]

cc @mayya-sharipova

[mayya-sharipova]

@stevejgordon Thank you for filling this issue. This was a design decision NOT to accept numbers with floating points, as we were considering to disable coercion altogether. But as we postponed disabling of coercion, I think it make sense for now to make unsigned_long consistent with other types and accept at least floating point numbers ending with .0