[JENKINS-66139] Avoid polluting the log if usage stats cannot be sent

[MRamonLeon]

See JENKINS-66139.

Avoid polluting the log when the usage statistics can't be sent. The full stack trace is printed as FINE. The message is printed as INFO because the instance is not compromised, so it's better to avoid disturbing the administrators.

Simple change, no test added. Manually tested:

Usual execution failing to send stats:

2021-07-14 15:35:52.544+0000 [id=31]    INFO    hudson.model.UsageStatistics#getStatData: Usage statistics could not be sent (Cipher available for WRAP_MODE and UNWRAP_MODE only)

Execution setting the FINE level to the UsageStatistics logger:

Jul 14, 2021 5:34:02 PM hudson.model.UsageStatistics getStatData
INFO: Usage statistics could not be sent (Cipher available for WRAP_MODE and UNWRAP_MODE only)
Jul 14, 2021 5:34:02 PM hudson.model.UsageStatistics getStatData
FINE: Error sending usage statistics
java.security.InvalidParameterException: Cipher available for WRAP_MODE and UNWRAP_MODE only
        at org.bouncycastle.jcajce.provider.BaseSingleBlockCipher.engineInit(Unknown Source)
        at org.bouncycastle.jcajce.provider.BaseSingleBlockCipher.engineInit(Unknown Source)
        at javax.crypto.Cipher.implInit(Cipher.java:805)
        at javax.crypto.Cipher.chooseProvider(Cipher.java:867)
        at javax.crypto.Cipher.init(Cipher.java:1252)
        at javax.crypto.Cipher.init(Cipher.java:1189)
        at hudson.model.UsageStatistics.toCipher(UsageStatistics.java:288)
        at hudson.model.UsageStatistics.access$100(UsageStatistics.java:76)
        at hudson.model.UsageStatistics$CombinedCipherOutputStream.<init>(UsageStatistics.java:247)
        at hudson.model.UsageStatistics.getStatData(UsageStatistics.java:192)
...

Proposed changelog entries

• Avoid polluting the log when usage statistics can not be sent

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[daniel-beck]

impossible

😕❓

[alecharp]

This is a 13yrs old line of code, coming from the subversion and the details on the commit is limited.
I'm not sure if the exception was not possible or if the instance was supposed to survive past a GeneralSecurityException.

How would you want this to be handled?

[timja]

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!