the create_workspace.sh script checks if a branch should be merged into
what we are trying to checkount (i.e., typically develop into
feature-branch). The problem is that it uses a short-hand for an if
branch.

    [ -n "${merge}"] && git merge...

If we don't request a merge, [ -n XX ] will evalute to 1, and not do the
git merge. Since it's the last command in the script, this makes the
script return 1 (failure), when it actually succeeded.

Add exit 0 to ensure we return 0 after successful end of the script. If
there is a failure, the script will terminate early. It can be tested by
e.g., giving a wrong commit ID.
Reviewed-by: Jaroslava Fiedlerova <Jaroslava.Fiedlerova@openairinterface.org>

Integration: `2024.w39`

Closes #846

See merge request oai/openairinterface5g!2990

* !2718 Added Jenkins job for Colosseum testing integration
* !2901 Fix log2_approx
* !2983 fix(docker): making tini download platform specific to support ARM64 native builds
* !2919 Add E2 SM in the target dockerfiles
* !2981 NR gNB fix PMI report evaluation
* !2979 NR-UE: Merging different UE NR SLOT FEP procedures into one.
* !2899 SIB19 initialization and scheduling on gNB
* !2953 Remove unnecessary c includes
* !2926 Fix SRS FAPI at gNB
* !2987 fix for variable power in PDSCH REs in case of 25 PRBs Bandwidth
* !2993 remove DRX from UE capabilities: not supported yet
* !2711 NR UE UL time alignment handling improvements
* !2995 some small fixes for 5G NR
* !2992 cleaner faster nr_pdcch_demapping_deinterleaving() inner loop
* !2986 NR PDCP ticks for F1 split
* !2982 CI framework cleanup

Merge remote-tracking branch 'origin/nr_pdcch_demapping_deinterleaving-improve' into integration_2024_w39

Currently, NR PDCP ticks are active only with monolithic gNB, triggered by the MAC scheduler in gNB_scheduler.c.
In F1 split mode, as there is no MAC, there’s no source to advance the NR PDCP timer via "nr_pdcp_wakeup_timer_thread()".
This commit introduces a dedicated thread for NR PDCP ticks in gNB-CU and CU-UP mode.
Without it, packet losses at the F1 uplink would cause indefinite buffering, as t-Reordering won't expire due to the lack of NR PDCP timer ticks.

Use a script, which can be tested independently of CI code (by running
it on the host on which it will be used), and print the directory that
has been prepared in the HTML.  Also, in the description, use the
infinitive/imperative(?) of the verb to harmonize with other steps.

A lot of CI code is python mixed with bash, e.g.,

    ssh = getConnection(host)
    ssh.run('ls')
    ssh.run('echo')

At least some of this CI code would benefit if it was written in a
simple bash script, returning error codes and potentially other
information either through stdout/stderr or files, to the calling Python
code:

    ssh = runScript(host, script)
    # script does: ls; echo

This commit introduces the possibility to run entire scripts. The idea
is that the executor has a script (on localhost), which is either
executed locally or on a remote host. For the remote host, the script is
not copied but piped into a remotely executed bash. In both cases,
output is either returned like the Cmd.run() function with returncode
and mixed stdout/stderr, or optionally redirected into a file on the
(remote) host, which can be treated further by the Python code in later
steps.

This reimplements the CI deployment functions, and makes them a bit more
robust.  Concretely:

- Introduce a generic "deployment tag" option that can be used to
  override the tag to use for specific images. By default, it is the
  current "branch-commitID[0:8]" tag name (requires the change from
  function ImageTagToUse() to CreateTag(), impacting also pull/push
  image functions)
- Avoid sed for image names, and use an .env file that docker-compose
  picks up automatically; the deployment analyzes a potentially existing
  .env file and updates instead of simply overriding. For instance, some
  pipelines might use -asan images for the gNB and "normal" (non-asan)
  images for UE, and a simple overwriting might make the -asan image
  name tag disappear for the gNB, resulting in deployment failures).
  Finally, undeployment removes the .env file, so that there are no
  modifications in the repository after undeployment.
- Redo the previous behavior of autodetecting asan, and use that (the
  current function always uses asan, no matter what)
- Remove deployKind/displayedNewTags globals, as they are not necessary
- Make the usedImage output in HTML slimmer
- On undeployment, print service names next to undeploy analysis, and
  return success/failure.
- Make the functions generally less verbose and easier to read

Note that as of and only in this commit, deployment does not work, as
all the YAML files have not been updated to work with this updated
version.  The next commit adds tests for the new deployment, and updates
one YAML file (also being used in the tests). The follow-up commit then
modifies all YAML files.

The BuildeNB steps either does things that are already implemented
(created workspace), or things that we don't use (separate build_wait),
and is generally quite convoluted when all it does is calling build_oai.
Reimplement by reusing Create_Workspace, and make build_oai in a single
step. To clean up, make a new module in which this function does not
need a class instantiation. Instead, we give all necessary parameters
directly.

The next commit will use "echo -e". The problem with that is that bash
and sh differ:

- in bash: this results in "a\nb" (a+newline+b)
- in sh: this results in -e a\nb (-e a+newline+b)

The problem is that by default, commands are executed through sh, which
nobody expects. Change to bash, which is likely more aligned with what
people want to use.

After the previous commit, the CI will always do an undeployment step
even if the CI failed. Hence, these XMLs are not necessary anymore. Some
XMLs are updated to do what their "cleanup XML" counterparts did, such
as removing additional images.

Use the previous commit on returning success from each task execution
function, and implement handling of errors in the main loop. Add a
script with which this is visible using Custom_Commands.

The repeatCount property is useless: it would be enough to specify the
same XML multiple times to achieve the same thing.