Fix recently translated Filebeat modules where integer coercions were added

[webmat]

Many of the recently Filebeat modules recently translated to ECS also added more integer coercion, for some of the fields that used to remain as strings (e.g. PID, port, etc).

This was done by adding :int in the grok expression, which may not be enough for all of these fields. We should review and use :long to perform the coercion where necessary.

Modules already merged, affected by this:

• Convert apache2.access to ECS - Take 2 #9245
• Convert Filebeat haproxy.log to ECS #9117
• Convert Filebeat iis.access to ECS #9084
• Convert Filebeat nginx.access to ECS #9081
• Convert Filebeat system.auth to ECS #9138
• Convert Filebeat system.syslog to ECS #9135

PRs already open, but not merged yet (should be fixed directly in their respective PRs):

• Migration of apache2 error fileset to ECS #8963
• Convert Filebeat elasticsearch.* to ECS #9293
• Convert Filebeat icinga.* to ECS #9294
• Convert Filebeat kafka.* to ECS #9297
• Convert Filebeat kibana.log to ECS #9301
• Convert Filebeat postgresql.log to ECS #9308
• Convert Filebeat redis.log to ECS #9315
• Convert Filebeat's traefik.access to ECS. #9005

This potential problem came up first here: #8963 (comment)

[ruflin]

I suggest we move all of them to long as we also convert type: int in the fields.yml automatically to long.

[webmat]

Yes, I agree. I'm even doing that for HTTP status codes, which are very far from overflowing the capacity of a signed int. I'm going for the most straightforward approach possible: "Always use long, don't overthink it" 😂

[webmat]

All PRs in flight have been adjusted to use :long for integer coercions