s3_auth: Fix assertion failure of TSActionCancel

[masaori335]

I faced below assertion failure with old expiration config of s3_auth plugin.

[Jan 23 16:34:50.071] [ET_NET 9] DIAG: (s3_auth) config expiration time is in the past, re-checking in 1 minute
Fatal: traffic_server/InkAPI.cc:1113: failed assertion `!"not reached"`
2023-01-23 16:34:50.071619+0900 traffic_server[79864:35081143] Fatal: traffic_server/InkAPI.cc:1113: failed assertion `!"not reached"`
Process 79864 stopped
* thread #11, name = '[ET_NET 9]', stop reason = signal SIGABRT
    frame #0: 0x00007ff818bcd30e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`:
->  0x7ff818bcd30e <+10>: jae    0x7ff818bcd318            ; <+20>
    0x7ff818bcd310 <+12>: movq   %rax, %rdi
    0x7ff818bcd313 <+15>: jmp    0x7ff818bc6dc2            ; cerror_nocancel
    0x7ff818bcd318 <+20>: retq
(lldb) bt
* thread #11, name = '[ET_NET 9]', stop reason = signal SIGABRT
  * frame #0: 0x00007ff818bcd30e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff818c04f7b libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007ff818b4eca5 libsystem_c.dylib`abort + 123
    frame #3: 0x00000000019b1faa libtscore.10.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") at ink_error.cc:99:3
    frame #4: 0x00000000019adebc libtscore.10.dylib`::_ink_assert(expression="!\"not reached\"", file="traffic_server/InkAPI.cc", line=1113) at ink_assert.cc:37:3
    frame #5: 0x0000000000033532 traffic_server`INKContInternal::handle_event_count(this=0x000000000303dcd0, event=1) at InkAPI.cc:1113:7
    frame #6: 0x000000000004a08f traffic_server`::TSActionCancel(actionp=0x00000000030344c1) at InkAPI.cc:7138:10
    frame #7: 0x0000000006f0b76f s3_auth.so`S3Config::schedule_conf_reload(this=0x0000000001e71b00, delay=60) at s3_auth.cc:489:7
    frame #8: 0x0000000006f0b11d s3_auth.so`config_reloader(cont=0x000000000303dcd0, event=TS_EVENT_TIMEOUT, edata=0x00000000030344c0) at s3_auth.cc:1070:11
    frame #9: 0x0000000000032f42 traffic_server`INKContInternal::handle_event(this=0x000000000303dcd0, event=2, edata=0x00000000030344c0) at InkAPI.cc:1137:29
    frame #10: 0x00000000000162ce traffic_server`Continuation::handleEvent(this=0x000000000303dcd0, event=2, data=0x00000000030344c0) at I_Continuation.h:227:12
    frame #11: 0x0000000000533564 traffic_server`EThread::process_event(this=0x0000000018228000, e=0x00000000030344c0, calling_code=2) at UnixEThread.cc:152:22
    frame #12: 0x0000000000533e4b traffic_server`EThread::execute_regular(this=0x0000000018228000) at UnixEThread.cc:258:11
    frame #13: 0x00000000005344e5 traffic_server`EThread::execute(this=0x0000000018228000) at UnixEThread.cc:337:11
    frame #14: 0x00000000005327b0 traffic_server`spawn_thread_internal(a=0x000060000211c000) at Thread.cc:79:12
    frame #15: 0x00007ff818c05259 libsystem_pthread.dylib`_pthread_start + 125
    frame #16: 0x00007ff818c00c7b libsystem_pthread.dylib`thread_start + 15

It looks like the S3Config::_conf_rld_act is tracking the reloading action. However, if the reloading is scheduled again, it tries to cancel the ongoing event. The event should be clear when the event handler starts handling the event.

trafficserver/plugins/s3_auth/s3_auth.cc

Lines 485 to 492 in 1426a06

	void
	schedule_conf_reload(long delay)
	{
	if (_conf_rld_act != nullptr && !TSActionDone(_conf_rld_act)) {
	TSActionCancel(_conf_rld_act);
	}
	_conf_rld_act = TSContScheduleOnPool(_conf_rld, delay * 1000, TS_THREAD_POOL_NET);
	}

[masaori335]

It turned out this fixes #9331. We need this for 9.2.1.

[zwoop]

Cherry-picked to v9.2.x