Webhooks to return a separate string field for content/attachment id

Issue Summary

Content/attachment id has a long type in Confluence and returned as an integer number in Webhooks. Therefore it's allowed for it to have a value up to 2^63 - 1. At the same time for an integer number JavaScript has a limitation of 2^53 - 1. Therefore if JavaScript code that handles webhooks, receives a content with id bigger than JS limit, it won't work correctly.

It wasn't an issue previously since content ids are not random and never reached such big numbers. However it started to happen already for tenants migrated from Server to Cloud which are set up to start their content ids from an arbitrary big number to avoid them being clashing with existing ids.

Returning content id as a string will resolve this issue, however it's a breaking change and will require some work to be done by app developers to handle an id as a string.

Steps to Reproduce

(high level)

1. Have an content with id > 2^53.
2. Have an app that listens for the webhooks.
3. Perform an operation with this content.
4. Receive a webhook in an app.

Expected Results

As a first phase we will be returning a separate idAsString field containing content id in a string format.

Actual Results

Content id in a webhook is a number.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available