DDAsyncInterceptor indirection slows down replicated reads

Local reads are fast enough, but the additional interceptors and stage callbacks in (transactional) replicated mode seem to impact with the async interceptor stack a lot more than the classic one.

One thing that's different with the new interceptors is that invokeNext() doesn't call command.acceptVisitor(nextInterceptor) directly. Instead it calls nextInterceptor.visitCommand(), and the interceptor decides whether to use double-dispatch (by extending DDAsyncInterceptor) or another strategy.

In theory this allows us to use simpler interceptors, e.g. having just the methods visitReadCommand(), visitWriteCommand(), and visitTxCommand(). CallInterceptor already calls command.perform() for each command. For now, however, most interceptors extend DDAsyncInterceptor, and tx replicated reads are slower than in 9.0.0.Alpha0.

With transactions, the VisitableCommand.acceptVisitor( call site in DDAsyncInterceptor.visitCommand is megamorphic (since the initial preload uses put, prepare, and commit). Adding a special check in invokeNext() to invoke command.acceptVisitor(nextInterceptor) didn't help, but adding a special check for GetKeyValueCommand made a big difference on my machine: