* De-experimentalize callback API
* Make FromServerContext based on ServerContextBase
* Fix lambda
* Fix headers
* De-experimentalize tests
* clang-format
* Fix consistency checks
* wip
* Fix const-ness of callback client read RPC requests
* Fix golden file
* Give full route_guide callback client example with Hold etc
* Complete example route-guide server
* De-experimentalize test services
* Omit unneeded using
* Remove some uses of non-experimental macro from test
* clang-format examples
* De-experimentalize async stub calls
* Remove experimental namespace use in qps, ubms
* De-experimentalize alarms, generic stubs, and context allocator
* De-experimentalize SetContextAllocator
* clang-format
* Fix conflicts
* Leave obsolete API in place until users can be migrated
The alarm is only used in the fixed-load scenarios, but its
construction is a major point of contention in both the closed-loop
and fixed-load scenarios. Delay its creation to when it is going to be
used, which will get rid of the contention in the closed-loop scenarios.
There aren't the right set of alarms in callback streaming reactor, so it exceeds the attempted qps while testing the fixed load streaming scenarios in synthetic benchmarks.
Every thread intitiates multiple RPCs. The Callback of the unary RPC then issues a new RPC and this goes until the benchmark shuts down. For shutdown the main thread waits on a conditional variable. After shutdown the callbacks increment a rpcs done variable and once the the rpcs done equate the the total number of outstanding rpcs, the last callback performing the increment operation also issues a signal to wake up the main thread. The mainthread process to join the other threads and perform cleanup