Avoid double checking if a tagged int string like `!!int '${variable}` is actually an integer

Is your enhancement related to a problem? Please describe.

I am extensively using Flux2 for Kubernetes GitOps deployments. They support variable substitution in YAML files as shown in https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution In essence, they just preprocess all YAML files and replace any ${variable_name} with whatever you have defined. However, when combining this with schema validation, whenever you use variables that require integers, numbers, etc break.

Given the following scheme

{
  "type": "object",
  "properties": {
    "string": {
      "type": "string"
    },
    "integer": {
      "type": "integer"
    }
  }
}

This obviously works

string: '1'
integer: 1

This also works nicely

string: !!str 1
integer: !!int '1'

But for the integer case, this does not work and will still throw an integer type error!

string: !!str '${asd}'
integer: !!int '${variable_that_turns_in_an_int}'

Describe the solution you would like

I think it makes sense that if you perform a manual cast like !!int the scheme validation system should simply accept that whatever follows is an integer. Not also try to cast it to an integer itself and if that fails, throw a type error.

Describe alternatives you have considered

I see no alternatives to fix this problem.

Additional context

The question is, could this be a breaking change as now in theory when you write !!int, there is no actual validation performed anymore on the string value (if it can be converted to an int). My personal opinion is that whenever you add a tag, you perform an explicit cast and don't care about more type checking.

The issue names no files or tests. Start by locating the schema-validation handling for YAML tags, then reproduce the examples using !!int with a variable placeholder. Done means an explicitly tagged integer placeholder is accepted without a second integer conversion, while the requested behavior and potential validation change are covered by tests.