Allow per-component configuration in Flux topology

[GGraziadei]

What is the purpose of the change

Add per-component configuration in the flux topology def grammar.

How was the change tested

• Unit test
• Submitting a flux topology with per component config
  Fix Flux support per-component configuration in BoltDef and SpoutDef #8710

[reiabreu]

Can we make a test where we are overriding topology-level configs?

[GGraziadei]

Hi, thank you for the comment. I totally agree, for coverage tree convenience, I am not adding a new test case, but compacting the scenario you proposed in this test case.

[rzo1]

Nice, well-scoped feature that rides on Storm's native component-config mechanism.

1. Bolt config is applied once per incoming stream, not once per bolt. The block applying memory/CPU/tasks/config runs on every iteration of the streams loop, so a bolt with N inputs calls validateFields() + addConfigurations() N times on the same declarer. It's idempotent, so not a bug, and it matches the existing pattern for setMemoryLoad/setCPULoad/setNumTasks (just redundant=
2. Validation asymmetry. buildConfig() applies the topology-wide config: with no ConfigValidation, while this PR validates per-component config. Fail-fast is the better behavior, but the asymmetry (an invalid-typed value passes topology-wide yet fails per-component) may surprise users. Consider validating the topology config too in a follow-up, or noting the difference.
3. README clarity. "Known Storm configuration keys are validated …" is accurate but could read as blanket validation. Suggest adding: "Unknown/custom keys are not validated and are passed through verbatim; validation runs client-side at build time."
4. Nit: new HashMap<String, Object>() in VertexDef → diamond <> to match the codebase.