Emit Jelly file path inside <script> tags to get better CSP samples

[daniel-beck]

This makes it easier to identify the source of a CSP violation from <script> tags in Jelly/Groovy views: Instead of the first 30 characters, we get a substring of the file path.

Additional benefit: If this isn't present, the source is something else (like an adjunct, or browser extension).

This is not a prerequisite for jenkinsci/jenkins#11269 nor vice versa, but this would complement the core change well.

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[Wadeck]

FTR from Daniel in Gitter:

It's a bit (very) limited given we're restricted to just 40 chars in Firefox at least, but perhaps this might end up useful?

[Wadeck]

nit suggestion: use //xxx instead of /*...*/ to save 2 characters as we seem to be lacking space

Daniel found the spec: https://www.w3.org/TR/CSP3/#violation-sample

A violation’s sample will be populated with the first 40 characters of an inline script, event handler, or style that caused an violation. Violations which stem from an external file will not include a sample in the violation report.

[daniel-beck]

save 2 characters as we seem to be lacking space

Seems less safe to do to me.

Also FTR I will need to confirm it's fine to not have //<![CDATA[ at the start of a block like this.

[daniel-beck]

Also FTR I will need to confirm it's fine to not have //<![CDATA[ at the start of a block like this.

Examples in https://developer.mozilla.org/en-US/docs/Web/API/CDATASection indicate <!CDATA[ can be put anywhere (and has no meaning in HTML), so inserting something before them should be fine.