[FIXED JENKINS-51037] Add ConcurrentSkipListSet to whitelisted classes

[jvz]

This adds ConcurrentSkipListSet to the list of default whitelisted classes for deserialization.

See JEP-200 and JENKINS-51037.

Proposed changelog entries

• Internal: added java.util.concurrent.ConcurrentSkipListSet to whitelisted classes for serialization.

Submitter checklist

• JIRA issue is well described
• Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
• 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

@reviewbybees @dwnusbaum @daniel-beck

[jglick]

Who is actually using a field of this type? Code reference? The JIRA issue gives no context. Generally we add whitelist entries only in response to observed failures.

I would also note that whoever is defining a persistent field of this type should stop doing so. Switch the field to some simpler type like Set; and, if the problem is via XStream define a readResolve to clean up old settings. (For Remoting usages, there is no diachronic consideration.) Whatever code is actually collecting entries concurrently can write out the result in a simple form when it is done.

[jvz]

It was in some wip code, but I can take a look into using readResolve instead.

[jvz]

Nevermind, this class isn't needed.

[oleg-nenashev]

For the record, I see no problem in adding it, just in case. But yes, we have different approaches on that with @jglick :D

[jvz]

I think it's better to be more explicit in your serialization anyways to avoid issues like this. I ended up using a proxy via readResolve/writeReplace.