MB-67857: Fix flakiness of menelaus_cbauth cbauth_sync_t

The test can race with setting up menelaus_cbauth_worker, because the
setup doesn't wait for this to be set up. The other tests weren't
impacted because they implicitly waited for this by waiting for the
initial UpdateDB call to be made. To ensure that cbauth_sync_t, and
any future tests, are not flaky, the setup function should wait for the
initial notification.

Change-Id: If8688e8d720196b49260fc2f2f65701d5e3eef77
Reviewed-on: https://review.couchbase.org/c/ns_server/+/232520
Reviewed-by: Steve Watanabe <[email protected]>
Tested-by: Peter Searby <[email protected]>
Well-Formed: Restriction Checker

Author: Peter-Searby

src/menelaus_cbauth.erl

@@ -712,7 +712,9 @@ start_fake_json_rpc_connection(Label) ->
     gen_event:notify(json_rpc_events,
                      {started, Label, [internal,
                                        {heartbeat, ?HEARTBEAT_TIME_S}],
-                      self()}).
+                      self()}),
+    %% Wait for initial notify to be handled, to avoid racy tests
+    meck:wait(1, menelaus_cbauth_worker, notify, ['_', '_'], ?LONG_TIMEOUT).
 
 cbauth_init_t() ->
     %% UpdateDB gets called once almost immediately
@@ -772,9 +774,6 @@ cbauth_stats_t() ->
     [] = stats().
 
 cbauth_many_notify_t() ->
-    %% Wait for initial notify to be handled
-    meck:wait(1, menelaus_cbauth_worker, notify, ['_', '_'],
-              ?LONG_TIMEOUT),
     meck:wait(1, json_rpc_connection, perform_call,
               ['_', "AuthCacheSvc.UpdateDB", '_', '_'], ?LONG_TIMEOUT),
     %% Ensure that the next perform_call doesn't immediately return