Fixed container build trigger and cleanup containers

[AhmedBM]

Description

• Fixed container build workflow trigger to dev
• Removed arm/arm64 container definitions
• Fixed debian-9 to use debian snapshot mirrors

Checklist

• I have read the contribution guidelines.
• I added unit-tests to validate my changes. All unit tests are passing.
• I have merged the latest dev branch prior to this PR submission.
• I ran pre-commit on my changes prior to this PR submission.
• I submitted this PR against the dev branch.

[github-actions]

Test Results

 44 files  ±0   44 suites  ±0   37m 6s ⏱️ - 2m 56s
  4 tests ±0    4 ✅ ±0   0 💤 ±0  0 ❌ ±0 
176 runs  ±0  154 ✅ ±0  22 💤 ±0  0 ❌ ±0 

Results for commit 595cd56. ± Comparison against base commit 81bd796.

♻️ This comment has been updated with latest results.

[MariusNi]

[robertwoj-microsoft]

We are failing some tests, for example here:

------
 > [9/9] RUN cd rapidjson && cmake . && cmake --build . --parallel --target install && rm -rf /git/rapidjson:
46.62 /git/rapidjson/include/rapidjson/document.h:2454:24: error: 'void* memcpy(void*, const void*, size_t)' forming offset [5, 12] is out of the bounds [0, 4] [-Werror=array-bounds]
46.62              std::memcpy(str, s, s.length * sizeof(Ch));
46.62              ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Seems we use rapidjson directly from master and have unpredictable builds. Have you considered freezing the library version similarly to how we do for cmake or gtest? I know the library does not really provide tags and is not versioned properly, but we could tie to a specific git ref. What do you think?

[AhmedBM]

We are failing some tests, for example here:

------
 > [9/9] RUN cd rapidjson && cmake . && cmake --build . --parallel --target install && rm -rf /git/rapidjson:
46.62 /git/rapidjson/include/rapidjson/document.h:2454:24: error: 'void* memcpy(void*, const void*, size_t)' forming offset [5, 12] is out of the bounds [0, 4] [-Werror=array-bounds]
46.62              std::memcpy(str, s, s.length * sizeof(Ch));
46.62              ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Seems we use rapidjson directly from master and have unpredictable builds. Have you considered freezing the library version similarly to how we do for cmake or gtest? I know the library does not really provide tags and is not versioned properly, but we could tie to a specific git ref. What do you think?

Yes, we do for some of the older distros but we really should be normalized across all distros. Ill see if i can lock down a version that works across all our supported distros

The issue is with distros where GCC>=9 (see Tencent/rapidjson#1700)

[MariusNi]

LGTM