[report] Fix html formatting for Plugin section

[jcastill]

After moving from .format() to f-strings via
57d2134, the formatting for Plugin sections was
lost. This patch attempts to fix this while still
using f-strings.

Related: #3780

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname [email protected]?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3781
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[TurboTurtle]

Two thoughts, no particular preference on either:

1. We are only using these in 2 places, we could simply do the f-string in-line instead of breaking it out into a function. We haven't really made any major changes to how the HTML reports are generated for in a very long time so I doubt we're going to be expanding the use of these any time soon.

2. If we keep it as a function, then we don't use camelCase in sos, and PEP8 explicitly discourages it

[jcastill]

Two thoughts, no particular preference on either:

1. We are only using these in 2 places, we could simply do the f-string in-line instead of breaking it out into a function.  We haven't really made any _major_ changes to how the HTML reports are generated for in a very long time so I doubt we're going to be expanding the use of these any time soon.

Fair enough. The problem I tried to solve was for example with PLUGLISTITEM, we have a definition for plain text and another one for html, and while setting the variable via f-strings was a bit tricky. Do you know if there's a pythonic way to use f-strings with strings defined as variables like PLUGLISTITEM?
Another option, perhaps, is to set a is_html boolean var, and if that's true, then add the html code, and if it's false (i.e. coming from the plain text report) then just print the var. Something like:

str_plugin = [ f"{value}" if not is_html else f'<td><a href="#{value}">{value}</a></td>\n' ]

2. If we keep it as a function, then we don't use camelCase in sos, and PEP8 [explicitly discourages it](https://peps.python.org/pep-0008/#function-and-variable-names)

Sorry, it seems that old habits die hard...

[jcastill]

Fair enough. The problem I tried to solve was for example with PLUGLISTITEM, we have a definition for plain text and another one for html, and while setting the variable via f-strings was a bit tricky. Do you know if there's a pythonic way to use f-strings with strings defined as variables like PLUGLISTITEM? Another option, perhaps, is to set a is_html boolean var, and if that's true, then add the html code, and if it's false (i.e. coming from the plain text report) then just print the var. Something like:

str_plugin = [ f"{value}" if not is_html else f'<td><a href="#{value}">{value}</a></td>\n' ]

Replying to myself: List comprehension won't be the best approach here, because we are concatenating the result. Perhaps an old fashioned if/then could be simpler.