Changes

hnbgw: Introduce PfcpParameters in TestHdlrParameters

This allows creating generic functions to establish PS RABs based on
test setup configuration.

Change-Id: I5de50bb7032891a073e4e4e25b2dc86bc84e3d60

bsc: testenv: set MTU=1500 for lo

Two tests are failing if the MTU is 65536 instead of 1500. This is an
upstream bug in titan.TestPorts.SCTPasp:
https://gitlab.eclipse.org/eclipse/titan/titan.TestPorts.SCTPasp/-/issues/3

Add a workaround so the behavior of the test environment is the same as
with docker-playground and the tests can pass again.

Related: OS#6602
Change-Id: Ifeda66954263fe8d2637377d0701a2208a19c332

hnbgw: Merge TC_ps_rab_assignment_* testcases

Change-Id: Ibfc3a7d74494bd78d8cfb4efa535ab4cd1b07cae

hnbgw: Move normal condition Iu Release procedure to helper function

Change-Id: I5dc7923b78d1b98fea1f71aa6e39c41f70b1f3e6

hnbgw: Tear down SCCP conn from CN under normal conditions

Specs mention that under normal conditions the CN is the one expected to
tear down the SCCP underlaying connection upon recieving
Iu-ReleaseComplete.

Change-Id: I920cabcb63ca352db0ed06e4c35dade52bae5399

testenv: fix 'container crashed' detection

* When the testsuite stopped and using podman, check if it stopped
  because the container crashed and raise an exception.

* Even after 9eb5e696 ("testenv: make podman stop more robust") it
  happens sometimes in jenkins that the container gets stopped on
  purpose because the testsuite is done, but then the watchdog process
  prints an error saying it crashed (without actually stopping testenv
  at this point). Change the message to a debug message that just says
  it stopped, this should not be an error.

Related: OS#6607
Change-Id: I3c116719cdc00a99e27e5237ba3d57d5258b0919

testenv: podman-main: set watchdog timer to 60s

Increase the timer from 10s to 60s, as with 10s I see jobs failing with:

  ERROR: /tmp/watchdog was not created, exiting

In theory 10s should already be enough, my guess is that if a jenkins
node is currently under a lot of load then the feed command may take
several seconds and so we hit the previous timer. Even if this is not
the cause, I think it is good to rule it out.

Exiting after 60s if the jenkins job was (manually / with connection
loss) aborted is still relatively quick.

Related: OS#6607
Change-Id: Ide7a9d5bc395106cdaa47cec3aa746a978674c9e