Fixing LCM startup correctness after D17824825

Summary:
This fixes a critical issue that was caused by D17824825 (cc. Vijaykumar) where for a short period of time we can have a nullptr logsconfig in the updateble logs config. In a race, the RSMs will attempt to locate sequencers for internal logs before LogsConfigManager executes its `start()` call, causing a null deref (undefined behaviour)

ASAN catches this on AdminServer startup in dev builds. Not really sure why this isn't visible on our integration tests (possibly will appear on stress tests)

Reviewed By: mcrnic

Differential Revision: D17978655

fbshipit-source-id: cb384e75b18dd8c04f7afbdf9e601f51bc5f69e1

Author: AhmedSoliman

logdevice/common/configuration/Configuration.cpp

@@ -67,6 +67,7 @@ void Configuration::getLogGroupByIDAsync(
   if (MetaDataLog::isMetaDataLog(id)) {
     cb(server_config_->getMetaDataLogGroup());
   } else {
+    ld_check(logs_config_);
     logs_config_->getLogGroupByIDAsync(id, cb);
   }
 }

logdevice/common/configuration/logs/LogsConfigManager.cpp

@@ -59,7 +59,10 @@ bool LogsConfigManager::createAndAttach(Processor& processor,
   std::unique_ptr<Request> req =
       std::make_unique<StartLogsConfigManagerRequest>(std::move(manager));
 
-  const int rv = processor.postRequest(req);
+  // We want to make sure that LCM has called start() (if needed) before the
+  // rest of the components execute their work, this ensures that the empty
+  // LogsConfig is published before the rest of dependencies.
+  const int rv = processor.blockingRequest(req);
   if (rv != 0) {
     ld_error("Cannot post request to start logs config manager: %s (%s)",
              error_name(err),