Allow Disabling Some Optimistic Concurrency Checks

[sklose]

It may be useful for gRPC services to opt-into disabling certain optimistic concurrency checks in order to increase throughput / availability. When a gRPC operation handler only reads state, but does not update state, we currently still go through the output sink to validate that the cached state is not stale. This is generally useful for services that scale up to multiple instances, but for specific use cases where there is only ever a single instance this check adds overhead. Proposed change:

1. the application configuration exposes a new setting that lets the user disable optimistic concurrency checks for for read-only APIs
2. another option that lets the application by-pass the entire output queue if the state is only read. This will be useful for on-prem installations where internet outages can happen - the service would still be able to service read requests, while write requests queue up in the output queue. However, this setting can only be supported in Concurrent mode, as RPC mode can generate sequence conflicts in a single instance.