tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8PL17


CVE: NA

----------------------------------------

It was found that running the LTP hotplug stress test on a aarch64
system could produce rcu_sched stall warnings.
The issue is the following:

CPU1 (owns the broadcast hrtimer)	CPU2

				tick_broadcast_enter()
				//shut down local timer device
				...
				tick_broadcast_exit()
				//exits with tick_broadcast_force_mask set,
				timer device remains disabled

				initiates offlining of CPU1
take_cpu_down()
//CPU1 shuts down and does
not send broadcast IPI anymore
				takedown_cpu()
				  hotplug_cpu__broadcast_tick_pull()
				  //move broadcast hrtimer to this CPU
				    clockevents_program_event()
				      bc_set_next()
					hrtimer_start()
					//does not call hrtimer_reprogram() to
					program timer device if expires equals
					dev->next_event, so the timer device
					remains disabled.

CPU2 takes over the broadcast duty but local timer device is disabled,
causing many CPUs to become stuck.

Fix this by calling tick_program_event() to reprogram the local timer
device in this scenario.

Signed-off-by: Yu Liao <liaoyu15@huawei.com>