More robust resolving of Delivery API redirects

[kjac]

Prerequisites

• I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes #16901

Description

As described in the linked issue, URL redirects can fail to resolve under certain conditions.

The culprit is how URL redirects are tracked - and how it changes over time, depending on content configuration:

• Sometimes a redirect is tracked solely by the original relative path
• Sometimes a redirect is tracked using the magic "root ID prefix" for the relative path - i.e. 1234/original/path

The magic "root ID prefix" seems generally to be applied when there are domains configured. Since redirects can be created both before and after domain configurations, we potentially have to look for both permutations when resolving redirect URLs for the Delivery API.

This PR updates the logic to be as follows:

1. If a redirect URL can be found at the naked route, use that.
2. If a redirect URL was not found, and a start item has been provided (which is recommended), use that as "root ID prefix" to resolve a redirect URL.
3. If a redirect URL is still not found, look for domain configurations matching the current request. If any match is found, use the mapped content item as "root ID prefix" in an attempt to resolve a redirect URL.

Testing this PR

First and foremost you'll likely need to use Postman to test this, and make sure that it's setup to not follow redirects automatically.

Test redirects for content structures

• With and without domain assignments.
• With one and with multiple root items.

The logic outlined above should provide test cases.

To explicitly verify that this PR fixes the linked issue

Create a content setup with:

• Multiple root items with children.
• Explicit, absolute and non-localhost domain mappings for all root items (hint: use localtest.me to be able to perform requests against them).

Request one of the children by path from the Delivery API using localhost and its corresponding start-item header.

Rename the child and re-publish it. This should result in a tracked redirect URL.

Request the child by path from the Delivery API again. The Delivery API should respond with an appropriate redirect.