stricter rate counter group allocation breaks applications

A recent patch to libosmocore refuses to allocate a rate counter group with an index that already exists. Per se that's a good thing, but it needs fixes in a whole range of callers. Numerous callers wrongly just pass 0 as rate counter group, so as soon as a second <thing> shows up, the application may deny service; that's unacceptable. For example, OsmoSGSN now crashes with the second subscriber showing up! causing patch: https://gerrit.osmocom.org/5418 my proposed change: https://gerrit.osmocom.org/5516 I'd like to request everyone to refrain from submitting patches that are insufficiently tested, in general of course, but in particular until after congress, please ;) ~N