Drop single-use service name constants i...

[harsh seal]

However, I have my doubts on this change and it being done everywhere

• There is no direct benefit
• The constant is actually used more than once (this PR shows it, it is used in tests)
• We have discussed using a services/actions string enum per component/integration to collect them instead in the past (a few exmaples/occurances of those exists actually in our codebase).

wdyt @lean matrix @valid igloo @last axle @blazing wedge

[last axle]

So we talked about this briefly in slack this week. And the conclusion kinda was like, yes, one could rename a constant value and it'd break setups and you wouldn't notice it

[worldly delta]

This came from a discussion I had with @valid igloo
Although it was more about "going forward", there is no much "copy-pasting" (that's the way it's done on integration X so I did it the same on integration Y) that I felt it was better to clean it up retrospectively as well (but not urgent)

[harsh seal]

Sure but that is like saying: Constants are bad 🤷‍♂️

[last axle]

While I do see a risk. I think it's a bit meh because reviewers know what to look for. If someone was renaming a DOMAIN, we'd flag that as well. We'd do the same with services IMO

[last axle]

We should get a role for Core, so we can easily tag ourselves

[harsh seal]

Haha yeah, I wrote exactly that down when I was writing that line

[valid igloo]

In general I don't really think constants is something to prioritize. There are other more important things to do.

I'd prefer that we stop this work with constants completely.

[worldly delta]

I think bsblan one makes sense to keep (tests have corrections about testing internals) - but the others can be closed

Or you can merge them, and I'll just stop creating new ones