DAOS-16016 test: Coverity 2555785 fix and run test_rebuild_35

[kccain]

Check return code of daos_cont_destroy() call in the test
rebuild_cont_destroy_and_reintegrate(). Also make sure that
test is actually executed at least in daily_regression CI.

Skip-unit-tests: true
Skip-fault-injection-test: true
Skip-func-hw-test-medium-md-on-ssd: false
Test-tag: test_rebuild_35
Test-repeat: 10

Before requesting gatekeeper:

• Two review approvals and any prior change requests have been resolved.
• Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
• Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
• Commit messages follows the guidelines outlined here.
• Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

• You are the appropriate gatekeeper to be landing the patch.
• The PR has 2 reviews by people familiar with the code, including appropriate owners.
• Githooks were used. If not, request that user install them and check copyright dates.
• Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
• All builds have passed. Check non-required builds for any new compiler warnings.
• Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
• If applicable, the PR has addressed any potential version compatibility issues.
• Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
• Extra checks if forced landing is requested
  • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
  • No new NLT or valgrind warnings. Check the classic view.
  • Quick-build or Quick-functional is not used.
• Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

[github-actions]

Errors are Unable to load ticket data
https://daosio.atlassian.net/browse/DAOS-16016

[kccain]

@phender and @daltonbohning I'm working on this separate patch due to DAOS-16016. The issue of extra time expenditure for new tests like this has come up in another PR #14584

This one I estimate will run in about 2 minutes of execution time (based only on running with tmpfs on a local developer cluster, not functional hw testing in CI). Is it worth adding that to per-pr testing? I can see an argument for covering the new rebuild tests (particularly any that are very lengthy) to be tested only as part of daily_regression (not pr). It's still better than what we have now, which is no regular coverage for a few of these recently-developed tests. What do you think for this one (pr,daily_regression or just daily_regression)? We can take a look at how the hw functional testing shakes out too, to confirm my time estimate.

[daltonbohning]

It's not just the test time of a single test that's the issue. It's when we add 2 minutes here, 2 minutes there, ... and suddenly we have several hours of PR testing. For rebuild specifically, this is a huge issue. Last I checked, there is something like 6-8 hours of rebuild pr testing. Which means even if a PR doesn't affect rebuild in any way, it still spends 6-8 hours running rebuild testing. (this is terrible for CI time and one of the contributors to slow turnaround times)

I can't tell you whether this test should be pr or daily or weekly because I don't know how likely it is to be affected by code changes. So instead, ask yourself

1. When pushing a PR, can you generally tell based on the code changes made that THIS test needs to be ran? And would using Features: rebuild be sensible?
2. How critical is this test? If this test fails, does it mean rebuild is effectively unusable? Or is it some edge case?

Realistically, we can't run everything in PR, so the idea is to mostly tag critical, quick tests with pr. Then, PRs should use Features to pull in additional test areas as needed. But at the same time, we don't have a perfect code <-> test mapping, so we don't always know whether we need to run a test.

[kccain]

Yeah I think this one is a bit specific to reintegration and can be run in daily_regression, and in Features: rebuild in certain PRs, so we catch any inadvertent regressions in a fairly timely manner

[daltonbohning]

Recommend rebuild tag here, so it's ran with Features: rebuild

Suggested change

	:avocado: tags=unittest
	:avocado: tags=unittest,rebuild

[kccain]

20 loops passed in CI functional hw testing (10 loops in functional HW medium, 10 loops in functional HW medium MD on SSD configuration). https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14619/3/

Ready for review