Multiple refactorings in common/app/layout

[shtukas]

What does this change?

Multiple refactorings in common/app/layout (to help with Onward refactoring). Notably segregate types into their own scala files.

[prout-bot]

Seen on PROD (merged by @shtukas 13 minutes and 41 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[rtyley]

Hi @shtukas ! We're doing the Scala 2.13 upgrade in #25190, and the match-exhaustiveness check has pointed out that PaidCard is not handled in this pattern-match expression in the template that renders FaciaCard instances on regular (non-commercial?) fronts:

frontend/common/app/views/fragments/items/facia_cards/item.scala.html

Lines 31 to 56 in 95f470a

	@item match {
	case paidContentOnEditorialPage: ContentCard if paidContentOnEditorialPage.branding.exists(_.isPaid) && !frontProperties.exists(_.isPaidContent) => {
	@paidContentCard(
	item = paidContentOnEditorialPage,
	omnitureId = mkInteractionTrackingCode(containerIndex, index, paidContentOnEditorialPage, containerDisplayName, frontId),
	containerIndex,
	index,
	isFirstContainer
	)
	}
	case content: ContentCard if isStoryPackage => {
	@dynamoContentCard(content, containerIndex, index, card.visibilityDataAttribute, isFirstContainer, isList)
	}
	case content: ContentCard => {
	@contentCard(content, containerIndex, index, card.visibilityDataAttribute, isFirstContainer, isList)
	}
	case htmlBlob: HtmlBlob => {
	<div class="@GetClasses.forHtmlBlob(htmlBlob)">@htmlBlob.html</div>
	}
	}
	}

....we were wondering what we should do to satisfy the compiler here? Have a blank case for PaidCard? There's already some logic around paidContentOnEditorialPage that seems to be in the same space?

[shtukas]

My instinct would be to maintain the existing behaviour and add a case for PaidCards but without rendering anything.