remove unnecessary needUpdate to avoid unexpected skipping updating before cache synced

[lxtywypc]

What type of PR is this?
/kind bug

What this PR does / why we need it:
Consider if some error occured in execution-controller, it would update the condition of work from true to false, and requeue in a short time(5ms for first time as default now), but during this reconciling, the condition of got work might be still true because the cache of work might not be synced yet. If no error occurs this time, when calling needUpdateCondition, we would find the condition in both "old" and "new" work status is true, that would cause unexpected skipping updating work status with the condition is false in cluster in fact.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:
I'm sorry for bringing this in #3808 , I intended to reduce the attempts to update work because now there are much more chances to update work status than before. But it seems quite a potential risk here. Maybe we could consider about a better way later to reduce the attempts to do unnecessary updating.

Does this PR introduce a user-facing change?:

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign garrybest after the PR has been reviewed.
You can assign the PR to them by writing /assign @garrybest in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/controllers/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[RainbowMango]

I'm sorry for bringing this in #3808 , I intended to reduce the attempts to update work because now there are much more chances to update work status than before. But it seems quite a potential risk here. Maybe we could consider about a better way later to reduce the attempts to do unnecessary updating.

I can't tell how bad it is right now. Please @XiShanYongYe-Chang take a look.

@lxtywypc Should we consider revert #3808?

[RainbowMango]

/assign @XiShanYongYe-Chang

[XiShanYongYe-Chang]

Ok, I will take a look ASAP.

[XiShanYongYe-Chang]

Hi @lxtywypc, thank you for your update. I indeed did not consider this point when reviewing it earlier. How did you discover it during testing?

[XiShanYongYe-Chang]

I can't tell how bad it is right now. Please @XiShanYongYe-Chang take a look.

@lxtywypc Should we consider revert #3808?

We don't need to revert the previously merged pull request. The purpose of this modification was originally to reduce the number of work updates, but due to possible delayed cache updates, it could result in an incorrect work status. After removing this logic, the work status can be correctly updated, although there may be some unnecessary update operations.

/lgtm

Ask an again review from @chaunceyjiang
/cc @chaunceyjiang

[lxtywypc]

How did you discover it during testing?

Due to that our testing environment sometimes need a little long time(for example 1s) for cache syncing. Once we noticed a work failed applied for a long time and tried to figure out what happened, we found that it had been applied successfully after once retry through the log of karmada-controller-manager. Then we found the potential risk of this part.

[chaunceyjiang]

/assign

[lxtywypc]

Draft for reverting #3808 as comment #3959 (comment)