feat(rules): expose rule.consequence.promote.objectIDs string array

[aallam]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	yes
Related Issue	Fix #694
Need Doc update	yes

Describe your change

Add support of the new field objectIDs. The tricky part here is to make this a discriminate union and not just make objectID & objectIDs optional, one of both needs to be set.

Note: a less aggressive change can be to simply add a new property with checks and logic operations in the setters, but this can be error-prone IMO.

[aallam]

For this change I would go for something simple: having two properties objectID and objectIDs.

Yes I was hesitating about this one, this means moving the error checking from compile-time to runtime (not the best DX IMO), but of course, if you think that the price to pay is too high, then we can go for the two properties solution.

[aseure]

@Aallam Thanks for the PR and I agree with everything that @Ant-hem already said. Just to give you a bit of context here:

Yes I was hesitating about this one, this means moving the error checking from compile-time to runtime (not the best DX IMO), but of course, if you think that the price to pay is too high, then we can go for the two properties solution.

Yes that's very true indeed. However doing that also has its advantages:

• if the engine does not consider it as an error anymore in the future (which already happened), the users won't get a compile-time error for something that now works
• it reduces the dev. cost at the company level of having an extra safety net at the API client level which is already implemented at the engine level
• if the engine improves its error messages, all users benefit from the change, not just the one who got the latest version of API client X, Y or Z