Remove 'slug' field on Document parts

[chaecramb]

What

Remove the slug field from document parts once all documents have had their link field populated in elasticsearch.

Why

A Search API document contains an array of parts which are built from information stored in the attachments key of details fetched from Publishing API. Previously, the parts contained only three attributes: slug, title, body. PR (#3271) added a link field to parts.

This new field is the fully qualified path for the part, which was necessary to deal with a bug where Finder Frontend lacked the information to correctly build links for parts where they have urls with an additional path segment. For example, consultation outcomes sit under <parent>/outcome/<part>.

The known document types that presented this issue, consultations and calls for evidence with outcomes, have been bulk republished in order to populate this field in elasticsearch.

Search API now tries to use link where it is populated and falls back to slug where it is not.

The slug field is now deprecated (#3325). Eventually slug should be entirely removed, but only after we are confident every document with either parts or attachments has had the link field populated.

[kevindew]

To add a little extra context to this issue.

The root of this problem is that there was an idea to display attachments on search results (example below):

And the approach to doing this was to extend the existing functionality which was to display these in the same way that documents with parts (e.g. foreign travel advice) do (example below) and thus combined these concepts together.

The approach we took to resolving the issue was to resolve the problem that using a slug field in parts is insufficient for this system to be used for attachments. With the expectation that parts in search results is now a different concept to the parts of document with parts because of it's dual usage and thus the divergence of slug to URL.

In resolving this it is probably most pragmatic to continue with the route of replacing the data in the parts to use link so it is compatible with both actual parts and attachments. However there is an alternative, more complex route, that'd be to separate attachments and parts as separate concepts. The latter would be of particular need if there was ever a need for a document to have both parts and attachments.