Only prevent command processing if streaming AND printing

Otherwise we might run into a rare race condition where the M110 sent
on start of a SD card upload gets prepared for sending after the
source file is already opened. That would then lead to the M110 not
getting processed anymore by OctoPrint and hence the line number
counter not resetting accordingly, leading to one line number
mismatch after the next from the firmware.

Testing if our "isPrinting" flag is ALSO set to true here ensures
that we'll only stop processing commands internally once the state
has actually switched to printing, which only happens after the
firmware responds to the M28 sent after the M110.

Fixes #1882 and probably also the issue encountered by @amd989 in
#1762 (which looks like exactly the same problem)

src/octoprint/util/comm.py

@@ -2163,7 +2163,7 @@ class MachineCom(object):
 		self._log("Closing down send loop")
 
 	def _process_command_phase(self, phase, command, command_type=None, gcode=None):
-		if self.isStreaming() or phase not in ("queuing", "queued", "sending", "sent"):
+		if (self.isStreaming() and self.isPrinting()) or phase not in ("queuing", "queued", "sending", "sent"):
 			return command, command_type, gcode
 
 		if gcode is None:
@@ -2432,17 +2432,17 @@ class MachineCom(object):
 		self._heating = True
 
 	def _gcode_M110_sending(self, cmd, cmd_type=None):
-		newLineNumber = None
+		newLineNumber = 0
 		match = regexes_parameters["intN"].search(cmd)
 		if match:
 			try:
 				newLineNumber = int(match.group("value"))
 			except:
 				pass
-		else:
-			newLineNumber = 0
 
 		with self._line_mutex:
+			self._logger.info("M110 detected, setting current line number to {}".format(newLineNumber))
+
 			# send M110 command with new line number
 			self._currentLine = newLineNumber