fix: return 400(StatusBadRequest) http code when the validation failed

[jwcesign]

What type of PR is this?
/kind bug

What this PR does / why we need it:
Currently, the webhook returns a 403 (forbidden) status code when validation fails. However, this is incorrect as it should only occur when there is insufficient privilege.

I have tested this with K8s and found that if the field is not correct, the expected status codes are either 400(StatusBadRequest) or 422(StatusUnprocessableEntity). Therefore, we should adhere to this rule.

There is no clear distinction between 400 and 422. In both cases, a parameter error occurs. Therefore, I have modified the relevant code to always return a response of 400.

Which issue(s) this PR fixes:
Fixes #none

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmada-webhook`: If the field validation fails, return a 400 (StatusBadRequest) HTTP code.

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign kevin-wangzefeng after the PR has been reviewed.
You can assign the PR to them by writing /assign @kevin-wangzefeng 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:

• OWNERS

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

[XiShanYongYe-Chang]

Thanks~
/lgtm

[RainbowMango]

Hi @jwcesign Could you double confirm it.
I just found the definition of HTPP code 403 from rfc9110:

The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden [target resource](https://www.rfc-editor.org/rfc/rfc9110.html#target.resource) MAY instead respond with a status code of [404 (Not Found)](https://www.rfc-editor.org/rfc/rfc9110.html#status.404).

Note that However, a request might be forbidden for reasons unrelated to the credentials.

I guess that's the reason why controller-runtime take 403 as the default code.

[jwcesign]

While reviewing the K8s code, I noticed that when there are invalid fields, it triggers the errors.NewInvalid function to return errors:

https://github.com/kubernetes/apiserver/blob/2538d7ca48d0ea82219d2fd963d728f7aecbacdf/pkg/registry/rest/create.go#L123

The NewInvalid function is quite old, as it originates from the first version of K8s (v0.2).

https://github.com/kubernetes/kubernetes/blame/a0abb3815755d6a77eed2d07bb0aa7d255e4e769/pkg/api/errors/errors.go#L97

[jwcesign]

Based on the information provided in this link (#3974 (comment)), it is recommended to close this PR.

[RainbowMango]

Yes, I think so. We are lack of evidence to accept this change. Thanks @jwcesign all the same~