[BUG] ISM API - put policy response uses `signed int` instead of long for `last_updated_time` value

[byi-esri]

What is the bug?

Using the current spec to generate Policy related code seems to be using an inappropriate type for a timestamp (currently using signed Integer).

Client side example: opensearch-project/opensearch-java#1717

java.lang.RuntimeException: Jackson exception: Numeric value (1755915614485) out of range of int (-2147483648 - 2147483647)
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 342]

How can one reproduce the bug?

Using a client that generates code based of the openapi spec, make PutPoliciesRequest. The summary object that is return fails to be deserialized because it's trying to stuff a long into an int.

What is the expected behavior?

Correct deserialization of the UNIX Epoch timestamp

What is your host/environment?

windows 11

Do you have any additional context?

Manually updating generated code on the client side to use longs for the timestamp field fix the error.

[krisfreedain]

Catch All Triage - 1 2