Page links don't get updated when copying a page tree via copypagehierarchy API

Issue Summary

Page links don't get updated when copying a page tree:

• One core feature in K15t Scroll Documents app is versioning, which is enabled by making copies of page trees using the copypagehierarchy REST endpoint.
• Customers of the app have been reporting that links within these page trees don't get updated when creating a version. The expected behaviour when I copy a page A with a child page B, and page A contains a link to page B, is that the copy of page A will link to the copy of page B, not to the original page B.
• This is a critical bug, as it affects a core feature in a popular app.

Steps to Reproduce

n/a

Expected Results

Usually I would expect page links to be stored like this in storage format: 

<ac:link><ri:page ri:content-title="Page" /></ac:link>

What we would need is one of the following:

• Either the editor needs to save links with proper page references again and all the links with absolute URLs that have been created in the meantime need to be migrated (this is the preferred solution, as I assume that absolute URLs cause more problems than just ours, for example during import/export)
• Or the `copypagehierarchy` REST endpoint needs to update absolute links

Actual Results

When I was testing recently with Confluence Cloud, I noticed that links were saved with absolute URLs:

<a href="https://cdauth.atlassian.net/wiki/spaces/D4/pages/1179451393/Page+4">Page 4</a>

This seems to have changed again. When I insert a link to a page now, it is inserted like this:

<ac:link ac:card-appearance="inline"><riage ri:space-key="D4" ri:content-title="Version (v1) of Page 4" ri:version-at-save="2" /><ac:link-body>Page 4</ac:link-body></ac:link>

Funnily, when viewing the page, this shows as a card with the page title, while in the export format (which we use for rendering the document), it shows the specified link body.

When I specify a link text manually, the links are still stored with an absolute URL.

Workaround

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