CHASM: support archetypeID in admin handler

[yycptt]

What changed?

• Accept archetypeID in admin API requests

Why?

• With this we no longer need to register chasm components to worker service, which currently performs an archetypeID to name conversion before calling admin apis.
• For backward compatibility, we can only stop registering chasm components to worker service starting from next cloud release.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

[bergundy]

Could you also remove the registration of the workflow and scheduler libraries from the other services?

[bergundy]

I wonder if anyone is going to use the numeric ID. What's the use case?

[yycptt]

I am thinking If any log message logs the ID or if we are looking at raw persistence records that would be useful.

but I guess I was also thinking: why not? It's optional anyway, and not complicating the logic a lot. The message is also clear re. the behavior. so I couldn't convince myself why not exposing it in tdbg.

[bergundy]

Could you also remove the registration of the workflow and scheduler libraries from the other services?

I see that we will need it for a while longer but let's make sure we do that soon.
We will want to break up all of the libraries into the component only parts and other parts with more dependencies for registration in the frontend to handle visibility APIs.

[yycptt]

Could you also remove the registration of the workflow and scheduler libraries from the other services?

I see that we will need it for a while longer but let's make sure we do that soon. We will want to break up all of the libraries into the component only parts and other parts with more dependencies for registration in the frontend to handle visibility APIs.

yeah that will have to wait until next cloud release. I will have the work tracked.