Optimize keywords-list logic in docs layout

[ashmaroli]

Proposed changes

The Liquid logic to render a list of keywords for a document consists of using a recursive
{% capture %} of words wrapped in an <a/> tag. This recursive capturing is inefficient both speed-wise and memory-usage-wise.

This pull request refactors the logic by:

• wrapping the core logic in a conditional that checks if page.keywords | split:"," results in a non-empty array right away.
• using Liquid's whitespace-control feature to conform to whitespace quirks of an HTML <span /> tag yet nest and indent Liquid markup for readability.

[thaJeztah]

LGTM!

thank you so much! there's quite likely more cleaning up / optimising in similar things; we've gathered quite some technical debt over the years, so thanks for doing these 🤗

[thaJeztah]

Just noticing this here (not needed to change as part of this PR); we should get rid of these inline styles, and either add a CSS class or add a style for glyphicon / glyphicon-tags to our stylesheet to do the padding.

Also need to check why we're adding the extra <span> here, and if instead we could use the <a> itself to do this (haven't tried yet)

[thaJeztah]

Also ok for a follow-up; we should remove the hard-coded https://docs.docker.com domain here. We're actually removing it again after generating the docs, so might as well just not add it in the first place 😂

[thaJeztah]

@usha-mandya ptal; I built this locally, and tag-links at the bottom of pages still rendered correctly with this patch, so I think it's good to go

[ashmaroli]

@thaJeztah Thank you for reviewing this.
Were you able to notice any improvement in the total build time with this branch?

[ashmaroli]

On the whole, total build times can be improved by reducing the work done by Liquid.
(Specifically, the logic for basehref (which is being removed in a different PR), the logic for liquid-only-toc and the logic for computing reading time of a page.

[thaJeztah]

Oh, I didn't time the build TBH (started a build and continued working on another project, 😅). We should definitely try to get rid of some of the weird "hacks" that are currently in place.

#10549 removes some of it; we know that PR is a bit risky, as there may still be broken links to markdown pages that moved, which is why we didn't merge it before the weekend 😂; even then: I much prefer actually fixing broken links at the source over "trying to fix them up during build" (or even with JavaScript 🙀).

I should note that with Mirantis having acquired the "enterprise" part of our products, soon the enterprise section will be fully migrated to the Mirantis documentation website, which will significantly reduce the number of pages in the docs (the enterprise section also has various archived versions included in the documentation)

[usha-mandya]

Thank you So much, @ashmaroli for cleaning this up. Thank you @thaJeztah for your insights.

[ashmaroli]

Thanks for the review and merge @usha-mandya 😃