Kinesis: In GetShardIterator request with AT_TIMESTAMP, timestamp is passed incorrectly based on CBOR Specification

### Describe the bug

The title is something I observed, but I expect that the bug applies to all places requiring timestamp.

I'm trying to migrate the integration tests communicating with Kinesis to LocalStack (pseudo-integration one), and observed the error from parsing CBOR request from LocalStack - `ValueError: year 54865 is out of range`. After sought codebase between AWS SDK Java and LocalStack, I figured out that AWS SDK Java does not respect the specification of CBOR.

https://www.rfc-editor.org/rfc/rfc8949.html#name-epoch-based-date-time

> Tag number 1 contains a numerical value counting the number of **seconds** from 1970-01-01T00:00Z in UTC time to the represented point in civil time.
> ...
> To indicate fractional seconds, **floating-point values** can be used within tag number 1 instead of integer values.

But the generator of CBOR in AWS SDK Java V2 calls `Instant.toEpochMilli()` which returns milliseconds as "integer", hence the value would be 1000 times than expected.

https://github.com/aws/aws-sdk-java-v2/blob/master/core/protocols/aws-cbor-protocol/src/main/java/software/amazon/awssdk/protocols/cbor/internal/SdkCborGenerator.java#L52

Note that the bug exists the same in AWS SDK Java V1, which I will file an issue separately.

### Expected Behavior

The timestamp value as number in CBOR is written as `.`, not `` as integer.

### Current Behavior

The timestamp value as number in CBOR is written as `` as integer, making general CBOR parser to fail to parse. e.g. ValueError: year 54865 is out of range when trying to parse the request via cbor python library.

### Reproduction Steps

I don't think this requires reproduction. It's obvious that the spec is not respected.

### Possible Solution

dividing by 1000 would simply fix the issue. Not sure Kinesis service would be affected after fixing this though.

### Additional Information/Context

_No response_

### AWS Java SDK version used

2.17.190

### JDK version used

OpenJDK 1.8.0_292

### Operating System and version

Not relevant to the OS