address how parameter callbacks work

[wjwwood]

There was a long discussion here: #495 (comment)

Basically right now you can only have one parameter callback at a time that can control whether or not parameters may be set.

Note this is about set_on_parameters_set_callback, but some parts of this discuss will apply to the "on change" callback which happens after setting occurs and is just for observation (it cannot reject changes).

This callback is considered insufficient because it makes having one callback per parameter or per group of parameters very difficult to implement. At first it seems trivial as the user could just have a single callback which calls multiple callbacks, but if the system also wants to have callbacks for things like implicitly declared parameters (e.g. use_sim_time) or callbacks to check changes to parameters based on some state (maybe lifecycle node's) then it's easy for the user to "clobber" system callbacks or even for system callbacks to interfere with one another.

One way to solve this is to have the NodeParameters interface handle this itself, allowing you to set more than one callback at a time. That would remove the burden from the users to coordinate and not interfere with each other.

However, if we do that we need a way to unregister callbacks that were registered (so some sort of receipt is needed), and we need a policy for what order to call them in and what to do if callbacks which overlap (check the same parameter) conflict. Do we stop at the first that fails or continue and aggregate the failure reasons?

---

This is my personal opinion on what we should do:

I think it should be a list of callbacks stored in the node, which is called in the order that they are added (perhaps with an option to prepend to the callback list for special cases), and we stop calling callbacks when the first one returns SetParameterResults.successful = false.

I'm not sure if it's worth calling all the callbacks so that we can take all the ones that failed and join their reasons, e.g. it might result in a reason like "failed to set parameters because: the node is not in the unconfigured state, and the parameter is not in the range x to y, and the parameter is read only" versus just one of them (the first one).