[trac931] added a test to reproduce the problem we had with addRemoteConfig.

Also added a note to the addRemoteConfig() document that when it's called
for a module the module cc session must not have been "started".

src/lib/config/ccsession.h

@@ -256,6 +256,10 @@ public:
      * for those changes. This function will subscribe to the relevant module
      * channel.
      *
+     * If the module name is specified (spec_is_filename is false), the
+     * ModuleCCSession must have been constructed with start_immediately
+     * being false and the \c start() method must not have been called.
+     *
      * \param spec_name This specifies the module to add. It is either a
      *                  filename of the spec file to use or a name of module
      *                  (in case it's a module name, the spec data is

src/lib/config/tests/ccsession_unittests.cc

@@ -595,4 +595,14 @@ TEST_F(CCSessionTest, delayedStart) {
                  FakeSession::DoubleRead);
 }
 
+// Similar to the above, but more implicitly by calling addRemoteConfig().
+// We should construct ModuleCCSession with start_immediately being false
+// if we need to call addRemoteConfig().
+// The correct cases are covered in remoteConfig test.
+TEST_F(CCSessionTest, doubleStartWithAddRemoteConfig) {
+    ModuleCCSession mccs(ccspecfile("spec29.spec"), session, NULL, NULL);
+    session.getMessages()->add(createAnswer(0, el("{}")));
+    EXPECT_THROW(mccs.addRemoteConfig(ccspecfile("spec2.spec")),
+                 FakeSession::DoubleRead);
+}
 }