[JENKINS-72111] Allow Lifecycle to load implementations from plugins

[jglick]

See JENKINS-72111 and #8555 (comment). Unlike the original PR, this requires no API change or plugin initializer, just the existing system property—which had long used UberClassLoader but did not work for a class defined in a plugin.

Testing done

The functional test added here, as well as validation that this works for a Lifecycle implementation in a plugin in CloudBees CI when the system property is set. (Without this patch, setting the system property to the plugin-defined class causes a boot failure, since the class is not loadable when Lifecycle.get is first called early during startup.)

Proposed changelog entries

• Allow plugins to define a custom Lifecycle.

Desired reviewers

@Vlatombe @jtnord

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. 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).

[jglick]

I retained sources in the plugin archive, but for the convenience of reviewers:

package test.custom_lifecycle;
import hudson.lifecycle.Lifecycle;
public final class CustomLifecycle extends Lifecycle {
    public int count;
    @Override
    public void restart() {
        count++;
    }
}

[jglick]

I found that UberClassLoader.loaded cached class loading misses after plugins were loaded during startup. This would not normally be noticeable, but in this case a call to Lifecycle.get before initializing plugins would cache the miss and it would not subsequently be cleared.

[jglick]

This is for dynamic plugin loading, so already cleared the cache, though also cache hits which seemed unnecessary.

[timja]

/label ready-for-merge

---

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

Thanks!