Possible race conditions in ServerRuntime.AsyncResponder

Multiple places in ServerRuntime.AsyncResponder check conditions in a read lock, release the read lock, acquire a write lock, and then make changes. Between releasing the read lock and acquiring the write lock changes could happen that would make the checks done in the read lock no longer valid. Below is an example of what appears to be a race condition where resume and cancel operations can both run.

* Thread1 calls resume() and [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L952) finds state is SUSPENDED and continues.
* Thread2 calls cancel() and [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L1014) find state is SUSPENDED and continues.
* Thread1 releases read lock
* Thread 2 release read lock
* Thread1 obtains the write lock
* Thread1 sets state to RESUMED [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L959)
* Thread1 release the write lock
* Thread2 obtains the write lock
* Thread2 sets state to RESUMED and sets canceled to true [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L1022). At this point Thread1 has already changed the state to RESUMED, so it does not seem like it should proceed.
* Thread2 releases the write lock
* Thread1 initiates resumption [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L963)
* Thread2 initiates cancelation [here](https://github.com/eclipse-ee4j/jersey/blob/268486ffc7c727542dddcf3a60bfbce24d3efd7b/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L1026)

Only looked at this code in isolation, so not sure if there are other mitigating factors outside this code that would handle this race condition.

Start in core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java and inspect AsyncResponder.resume() and cancel() around the linked lines, including their read-to-write lock transitions. Reproduce or reason through the interleaving described in the issue, then ensure the stale state checks cannot allow both operations to proceed and validate the resulting behavior with regression coverage.

Written by the indexing model from the issue text.