Reduce lock scope in StringHelper#randomId()

[easyice]

This change moves BigInteger#toByteArray() outside the synchronized block, since it allocates and copies data. this method does not seem to be on a hot path, so the performance impact may be minimal.

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!

[msfroh]

@easyice -- I don't know the Java lock semantics well enough to know which is more expensive, acquiring a mutex or using an AtomicReference. I get the impression that if you have contention, the mutex will do better (since the atomic ref may need to retry the update), but if you usually don't have contention, the atomic ref will be better.

I was able to get rid of the lock altogether (replacing it with optimistic locking from getAndUpdate) here: a946e65

I honestly don't know if that's any better though. As you said in the description, the impact may be minimal anyway.

[easyice]

@msfroh This makes sense to me. My understanding is that CAS only becomes less efficient than locks under very high retry contention. For the randomId method, it should be a good fit, and it also makes the code more readable.

Could you open a new PR for this, or push the change here?

[msfroh]

Sure thing, @easyice! I've opened a new PR here: #15805