[JENKINS-67344] Poor performance of UpdateSite.getData

[basil]

Profiling showed that while regex compilation was indeed a problem, it wasn't the bottleneck. The real bottleneck was repeatedly copying a massive string just to search a few characters in it. Fixed by copying just the portion of the string we need to search. See flame graphs before and after.

Next steps

If merged and deployed to Jenkins users successfully, I will try to propose this upstream at https://github.com/kordamp/json-lib.

Testing done

Tested against the real Jenkins Update Center JSON file; execution time went from about 8 seconds to about 0.4 seconds consistently. Tested interactively in Jenkins as well; the "Refresh" button on the plugin update page is now bounded by download time, not CPU time, and for me goes from about 12 seconds to about 5 seconds.

[basil]

Oops, I pushed this to master before I had intended. In any case, happy to respond to any review after the fact.

[basil]

(The version I pushed to master has commit f5aa4ac, which is what I had intended to update this PR with, but pushed to the wrong branch)

[MarkEWaite]

Change looks good to me.

[jglick]

So 7a7f18e...f5aa4ac to avoid

json-lib/src/main/java/net/sf/json/util/JSONTokener.java

Lines 108 to 111 in f5aa4ac

	public boolean matches(String pattern) {
	String str = this.mySource.substring(this.myIndex);
	return RegexpUtils.getMatcher(pattern).matches(str);
	}

which is going to be inefficient (especially if the document is not strictly ISO-8859-1 as in the case of the UC). Thanks for fixing this long-standing problem!