Any extension that calls invocation.proceed() multiple times like @Retry misbehaves

[Vampire]

Describe the bug

MethodInvocation has an Iterator for interceptors.
If you call invocation.proceed(), then the iterator is queried for the next interceptor which is then invoked.
So if you call invocation.proceed() a second or further time, all subsequent iterators for that method invocation are not invoked.

MethodInvocation is pretty thin state-wise.
For most things it is just a data-holder.
The only things that are directly stateful are when setArguments(...) is called and when proceed() is called.

I guess the most proper solution would be to replace this.arguments = arguments; by System.arraycopy(arguments, 0, this.arguments, 0, arguments.length); and getting rid of the iterator for interceptors, but instead having an own MethodInvocation for each interceptor that knows the next interceptor to call.

This should be a backwards compatible change and fix all extensions that might do something similar to what @Retry does.

To Reproduce

• Have a global extension (don't forget to register it in META-INF/services) like

  class GlobalRetryExtension implements IGlobalExtension {
     private final Retry retry = Retried.getAnnotation(Retry)
  
     private final RetryExtension extension = new RetryExtension()
  
     @Override
     void visitSpec(SpecInfo spec) {
        if (!spec.getAnnotation(Retry)) {
           extension.visitSpecAnnotation(retry, spec)
        }
     }
  
     @Retry(mode = SETUP_FEATURE_CLEANUP)
     private static final class Retried {
     }
  }

• Have a specification with a @TempDir field
• Make sure the specification fails so that it is retried

Now either set breakpoints in the RetryIterationInterceptor and TempDirInterceptor, or check in the feature the presence of the temp dir, or similar.

Expected behavior

Retrying (and any interceptors doing something similar) should properly invoke subsequent interceptors each time.

Actual behavior

With non-suspending breakpoints that do some logging on the two mentioned interceptors, one on the proceed() line and one on the following line for each, you get output like:

retry try
temp dir: .../spock_build_should_fail_i_0_rootDir6715396349974787942
temp dir destroy:.../spock_build_should_fail_i_0_rootDir6715396349974787942
retry after try
retry try
retry after try
retry try
retry after try
retry try
retry after try

Dependencies

Spock 2.3-groovy-3.0