Add optional aliasPaths to Content + Crier's RetrievableUpdate

[JustinPinner]

What does this change?

The evolving URLs work has highlighted a need to make alias paths available in CAPI responses, in particular to service de-caching operations where an item of content may have been cached under any or all of its prior paths.

In this PR we are adding an optional list<string> aliasPaths to the v1.content representation, and to the RetrievableUpdate type in Crier. The former will allow Concierge to include the data in its responses, and the latter will allow Crier to pass that data on in its update messages.

The reason we need the data in both places is because the content is not guaranteed to be available in the message payload when the cache purger receives it (hence the existence of the RetrievableUpdate type), but in this case we don't want to introduce a lookup back to CAPI, which could fail, when a purge is required.

How to test

I have compiled the models locally and tested that CAPI returns aliasPaths when requested. This is sufficient to know that regular updates with a v1.Content payload is received by the cache purger. I'll explore further tests when looking at the changes needed in Crier.

How can we measure success?

Taking an item of content with some URL evolution history;

1. When CAPI is requested to show the aliasPaths data for the content, it will. Further, it will not include that data unless specifically asked for it.

2. When an update or delete occurs for the item, we see all the appropriate de-cache events generated for the aliasPaths provided.

Have we considered potential risks?

The risks here are minimal. As it is new data, no existing interpreters will be affected, and as the data is also optional, no changes will be evident unless consumers specifically request it.

Images

N/A