feat: Add TemplatesStatus field to InstanceSetStatus

[YTGhost]

resolve #7400

[YTGhost]

@weicao @free6om Two more points might need to be discussed:

1. In the design of the KB, the InstanceSet is used as an internal object, so should the TemplatesStatus also be mapped to the upper-level Component?
2. As the number of InstanceTemplates increases, the data displayed here will also increase. Is it necessary to add a switch to let users choose whether to enable TemplatesStatus?

[weicao]

@weicao @free6om Two more points might need to be discussed:

1. In the design of the KB, the InstanceSet is used as an internal object, so should the TemplatesStatus also be mapped to the upper-level Component?

The Component is also an internal object. I think it's all right to observe&watch the status of internal objects. So it's fine to put TemplatesStatus in InstanceSet right now.

2. As the number of InstanceTemplates increases, the data displayed here will also increase. Is it necessary to add a switch to let users choose whether to enable TemplatesStatus?

Will the InstanceSet CR exceed maximum size in kuaishou's environment if TemplatesStatus is added?

[free6om]

@weicao @free6om Two more points might need to be discussed:

1. In the design of the KB, the InstanceSet is used as an internal object, so should the TemplatesStatus also be mapped to the upper-level Component?

I would treat the main target of this PR as to resolve the Karmada Interpreter related issue, and prefer to keep the top Cluster&Component APIs as simple as possible.
We can discuss the observation of spec.componentSpecs[x].instances of Cluster API level in another issue.

2. As the number of InstanceTemplates increases, the data displayed here will also increase. Is it necessary to add a switch to let users choose whether to enable TemplatesStatus?

Base on one test we did before, 200 items of TemplatesStatus is a safe bar against object size, you can do an evaluation of your use scenario.

[YTGhost]

I would treat the main target of this PR as to resolve the Karmada Interpreter related issue, and prefer to keep the top Cluster&Component APIs as simple as possible.
We can discuss the observation of spec.componentSpecs[x].instances of Cluster API level in another issue.

Sure

Base on one test we did before, 200 items of TemplatesStatus is a safe bar against object size, you can do an evaluation of your use scenario.

We have at most a few dozen templates in our scenario, so this is completely sufficient.

@free6om So, it looks like we can merge this PR now?

[free6om]

/cherry-pick release-0.9

[github-actions]

🤖 says: cherry pick action finished successfully 🎉!
See: https://github.com/apecloud/kubeblocks/actions/runs/9951040374