freertos: call tick hooks on CPU1 even if CPU0 scheduler is suspended

The block which dispatches ticks on CPU1 was a copy of the code block
for the normal path (CPU0). It used to check uxPendedTicks, with the
logic that uxPendedTicks can be 0 iff the scheduler is not suspended.

On CPU1 however, uxPendedTicks is not related to the state of the
scheduler (as uxPendedTicks is updated on CPU0). Due to this, if CPU0
scheduler was suspended, and uxPendedTicks happened to be nonzero,
tick hooks on CPU1 didn’t run, even though CPU1 scheduler was working.

This change removes the check for uxPendedTicks in CPU1 code path,
so that the tick hooks on CPU1 always get called (as for the CPU0 code
path).

components/freertos/tasks.c

@@ -2381,26 +2381,15 @@ BaseType_t xSwitchRequired = pdFALSE;
 	   switch, even when this routine (running on core 0) unblocks a bunch of high-priority
 	   tasks... this is less than optimal -- JD. */
 	if ( xPortGetCoreID()!=0 ) {
+		#if ( configUSE_TICK_HOOK == 1 )
+		vApplicationTickHook();
+		#endif /* configUSE_TICK_HOOK */
+		esp_vApplicationTickHook();
+
 		/*
 		  We can't really calculate what we need, that's done on core 0... just assume we need a switch.
 		  ToDo: Make this more intelligent? -- JD
 		*/
-		{
-			/* Guard against the tick hook being called when the pended tick
-			count is being unwound (when the scheduler is being unlocked). */
-			if( ( uxSchedulerSuspended[ xPortGetCoreID() ] != ( UBaseType_t ) pdFALSE ) || uxPendedTicks == ( UBaseType_t ) 0U )
-			{
-				#if ( configUSE_TICK_HOOK == 1 )
-				vApplicationTickHook();
-				#endif /* configUSE_TICK_HOOK */
-				esp_vApplicationTickHook();
-			}
-			else
-			{
-				mtCOVERAGE_TEST_MARKER();
-			}
-		}
-
 		return pdTRUE;
 	}