Introduce a build time optimized FastComponentNameResolver

[jamesnetherton]

No description provided.

[ppalaga]

Does this prevent end users from adding their own components via service loader? For some reason, I do not see any invocation of ComponentNameResolver.resolveNames() in Camel or Camel Quarkus source tree to figure out myself.

[jamesnetherton]

Does this prevent end users from adding their own components via service loader?

No, the components will still get registered. But I did realise something with the build time catalog that I wrote recently, in that doing discovery via these annotations may not work with old style components because it's a Camel 3 construct. Hence my question on Zulip about CamelServiceBuildItem.

[davsclaus]

Yeah it looks like I added this API in 2020 for some use-case but we didn't need it anyway, so its not in use currently. However it can be used to find which components are available on the classpath in Camel if needed (maybe for logging, diagnose, jmx management etc.)

[jamesnetherton]

it can be used to find which components are available on the classpath in Camel if needed

I was thinking of using it for something I have planned as part of #2914. But the DefaultComponentNameResolver doesn't actually work in native mode at the moment because the component service resources are not added to the native image (which circles back to my Zulip question). And is partly why I created this PR.

[ppalaga]

Thanks for the context, it is much clearer to me!