Locking path in Firebase wrongly assumes two path segments for one-off items

[joepie91]

Given the following two fictitious data paths in Firebase:

/buckets/example.com/foobar/dev/data/about
/buckets/example.com/foobar/dev/data/article/1

... where about is a one-off content type, and posts is a 'regular' content type, the lock paths would look something like this:

/buckets/example.com/foobar/dev/presence/locked/data/about
/buckets/example.com/foobar/dev/presence/locked/article/1

While the second one would be correct, the first one is not - I haven't looked at the code for this, but the CMS appears to simply take the last two path segments of the data path when generating the lock path; this assumption breaks down for one-off items, as those only have a single path segment identifying the item.

The (possible) consequences:

1. Given that Webhook uses Firebase, there's no formal schema - the buggy path generation has now become part of the informal scheme, and other tools interacting with the Webhook database need to reimplement the bug.
2. If a content type named data were to ever exist, and it were to contain an item with a key equalling the name of a one-off content type, this would create a lock name collision - and potentially break editing as a result.