Guard against thread double starting

[broneill]

The Thread class has a flawed design because it implements the Runnable interface. This allows threads to be started again via direct invocation of the run method, which leads to unpredictable behavior. A plugin which is running from a thread pool can obtain the current thread, and then start new threads which enter the thread pool code itself. Ideally, all Runnable instances and all Thread subclasses should prevent double invocation of the run method, but this is seldom done in practice. It should be noted that virtual threads aren't affected by this design flaw since it implements a run method which always does nothing.

The original security manager never guarded against this flaw, because it didn't deny obtaining the current thread. Access can be denied when using Boxtin, but this might be too restrictive. Denying the ability to start new threads isn't effective, because the run method can still be called directly from the current thread. In addition, new tasks can be started using the common ForkJoinPool, and this action wasn't denied by the original security manager either.

This feature should modify classes such that direct invocation of the run method is denied. Modifications need to be applied to the Thread class, and to the run method of all Thread subclasses.

This feature might cause issues in cases where double or indirect invocation of the run method is intended, and so controls should be added to disable the feature on a package or class basis.