osmo_fsm_inst_state_chg(): set T also for zero timeout

Before this patch, if timeout_secs == 0 was passed to
osmo_fsm_inst_state_chg(), the previous T value remained set in the
osmo_fsm_inst->T.

For example:

  osmo_fsm_inst_state_chg(fi, ST_X, 23, 42);
  // timer == 23 seconds; fi->T == 42
  osmo_fsm_inst_state_chg(fi, ST_Y, 0, 0);
  // no timer; fi->T == 42!

Instead, always set to the T value passed to osmo_fsm_inst_state_chg().

Adjust osmo_fsm_inst_state_chg() API doc; need to rephrase to accurately
describe the otherwise unchanged behaviour independently from T.

Verify in fsm_test.c.

Rationale: it is confusing to have a T number remaining from some past state,
especially since the user explicitly passed a T number to
osmo_fsm_inst_state_chg(). (Usually we are passing timeout_secs=0, T=0).

I first thought this behavior was introduced with
osmo_fsm_inst_state_chg_keep_timer(), but in fact osmo_fsm_inst_state_chg()
behaved this way from the start.

This shows up in the C test for the upcoming tdef API, where the test result
printout was showing some past T value sticking around after FSM state
transitions. After this patch, there will be no such confusion.

Change-Id: I65c7c262674a1bc5f37faeca6aa0320ab0174f3c

1 files changed, 4 insertions, 0 deletions

diff --git a/tests/fsm/fsm_test.ok b/tests/fsm/fsm_test.ok
index e69de29b..c3536fba 100644
--- a/tests/fsm/fsm_test.ok
+++ b/tests/fsm/fsm_test.ok
@@ -0,0 +1,4 @@
+T = 42
+T = 0
+T = 42
+T = 11