[CHORE] Say what the code does rather than what it stopped doing

Three comments described the change relative to the previous shape: a bound that
is "unchanged", a lock that was taken out, and an ordering that "no longer" comes
from the curl client. A reader of the file has no previous shape to compare
against, and the rationale for the change is in this PR.

Each now states the current fact: what response_timeout_ bounds, that nothing
serialises ForceFlush against Shutdown, and that the curl client does not produce
the ordering the case pins while another client may.

Signed-off-by: thc1006 <84045975+thc1006@users.noreply.github.com>

Author: thc1006

exporters/elasticsearch/src/es_log_record_exporter.cc

@@ -606,12 +606,10 @@ bool ElasticsearchLogRecordExporter::ForceFlush(std::chrono::microseconds timeou
   timeout = opentelemetry::common::DurationUtil::AdjustWaitForTimeout(
       timeout, std::chrono::microseconds::zero());
 
-  // A caller that asks for no deadline still gets one, because a flush that cannot end is worse
-  // than one that reports it did not finish, and the client is not obliged to call back at all.
-  // response_timeout_ is the bound this wait already had before the accounting was fixed, and it
-  // is the same value the request itself is given, so a session outstanding when the watermark is
-  // taken has at most that long before the client owes it a terminal event. The bound is
-  // unchanged; what changes is that running out of it no longer reports success.
+  // A caller that asks for no deadline still gets one: a flush that cannot end is worse than one
+  // that reports it did not finish, and a client is not obliged to call back at all.
+  // response_timeout_ is the same value the request itself is given, so a session outstanding when
+  // the watermark is taken has at most that long before the client owes it a terminal event.
   if (timeout <= std::chrono::microseconds::zero())
   {
     timeout = std::chrono::seconds{options_.response_timeout_};

exporters/elasticsearch/test/es_log_record_exporter_test.cc

@@ -761,10 +761,10 @@ TEST_F(ElasticsearchForceFlushTests, ANoDeadlineFlushGivesUpAtTheResponseTimeout
   EXPECT_GE(ms, 1000) << "returned without waiting, so the bound is not the response timeout";
 }
 
-// ForceFlush() and Shutdown() are required to be safe to call concurrently, and this PR took out
-// the lock that used to serialise them, so the overlap is deterministic here rather than left to
-// chance: the flush is parked on its session before the shutdown starts. A real client answers
-// its outstanding sessions while shutting down, which is what has to wake the waiter.
+// ForceFlush() and Shutdown() have to be safe to call concurrently and nothing serialises them,
+// so the overlap here is arranged rather than left to chance: the flush is parked on its session
+// before the shutdown starts. A real client answers its outstanding sessions while shutting down,
+// which is what has to wake the waiter.
 TEST_F(ElasticsearchForceFlushTests, AParkedFlushIsWokenByTheShutdownThatCompletesItsSession)
 {
   std::shared_ptr<http_client::EventHandler> captured;
@@ -1315,9 +1315,9 @@ TEST_F(ElasticsearchAsyncCompletionTests, TwoTerminalEventsCountAsOneSession)
       << "the second session is still in flight";
 }
 
-// The curl client's completion lambda tests the response first and the abort in an else, so this
-// ordering no longer comes from it. It still comes from anywhere: EventHandler promises callers
-// nothing about how many terminal events arrive, and #4360 is open on exactly that.
+// The curl client's completion lambda tests the response first and the abort in an else, so it
+// does not produce this ordering. Another client may: EventHandler promises callers nothing about
+// how many terminal events arrive, and #4360 is open on exactly that.
 TEST_F(ElasticsearchAsyncCompletionTests, CancelledThenAResponseCountsOnce)
 {
   std::vector<std::shared_ptr<http_client::EventHandler>> kept;