transform bodyXMLto external content-tree in Go

[lokendersinghft]

This PR introduces a Go-based bodyXML → content tree transformer. The new transformer produces output in 1:1 parity with the current Node.js implementation, with the following differences:

• Experimental blocks: If an experimental block contains an unrecognised
  or nested elements that do not conform to the content tree schema, this transformer throws an error.
• Tweet: Unlike the existing Node.js transformer, this implementation supports "tweet" tags.
• Clipset: A Clipset type is defined in Go, and transformation logic has been implemented. This logic can be refined further as needed.

JIRA --> https://financialtimes.atlassian.net/browse/UPPSF-6453

[epavlova]

This is very important bit of the journey 👏

[epavlova]

thought (non-blocking): This is just food for thought. The JSON schemas have stricter rules than what we represent with the Go types. So I am thinking that we may want to still validate what is produced by this Transform. But I think it's better to do so where this Transform is used, in our case in the Content Tree API.

[epavlova]

suggestion: I am pretty sure that some old content pieces will have:
"http://www.ft.com/ontology/company/Organisation", let's add this one as well.

[lokendersinghft]

I mimicked the transformation we perform in content-public-read. I don't see this URL their in the configs.

content-public-read

[lokendersinghft]

Should we map http://www.ft.com/ontology/company/Organisation to /organisations/{{id}}?

[epavlova]

I think my previous comment is not very useful. I saw that contentTypeTemplates is used in generateUrl and used in mapping t.Tag == "concept". However if we need to count for the <concept>/<ft-concept> tags, then we need to support a full mapping of all concepts that could go in the tag like Organisation, Person, etc
However we decided that we are going to remove the tag as part of @vlasakievft efforts to clean the historical content.
@lokendersinghft I suggest to keep the list as it is. At some point the transformer shouldn't need to work with <concept>/<ft-concept>.

[todor-videv1]

question, thought: Do we want to return this root node from the transformer? Isn't it the idea to give old (and new content published without tree) a tree body representation using this transformer. The current schema we use for validating payloads expects the following format:

{ "type": "body", "version": 1, "children": [ { ...

[lokendersinghft]

We decided to keep it this way so that we can easily introduce stuff to it later.

[todor-videv1]

suggestion (non-blocking): Consider whether you can separate the convertToContentTree into smaller methods. For example one for the case *etree.Element and one for the *etree.CharData. In this way you would avoid the nested switch statements.

[todor-videv1]

suggestion(non-blocking): Consider this:

type contentType = string
const (
	ImageSet            contentType = "http://www.ft.com/ontology/content/ImageSet"
	Video                           = "http://www.ft.com/ontology/content/Video"
	Content                         = "http://www.ft.com/ontology/content/Content"
	Article                         = "http://www.ft.com/ontology/content/Article"
	CustomCodeComponent             = "http://www.ft.com/ontology/content/CustomCodeComponent"
	ClipSet                         = "http://www.ft.com/ontology/content/ClipSet"
)

[todor-videv1]

nitpick: internalcomponents collection.

nitpick: Maybe we can expand the description slightly to mention what is the difference between the two representations supported by the transformer.

[lokendersinghft]

I have added tad bit of more information on this.