Protect document state with recursive lock and add objectDidChange publisher

[jessegrosjean]

This gives Document an .objectDidChange publisher, that is fired in sync with and immediately after changes are made to a document. This required two changes:

1. Protect document state with a NSRecursiveLock instead of a dispatch queue. This is needed because I want to be able to call back to the document from my .objectDidChange listener without creating deadlock in the queue.
2. Add an optional (when combine is available) .objectDidChange publisher that always balances the current .objectWillChange publisher.

resolves #178

[heckj]

Can you add a bit of doc comment here highlighting that this is triggered explicitly after the document has been updated, and use your use-case as a "for example"? i.e. "Sends a signal that the document has been updated. For example, you can use this signal to retrieve heads for the document to capture the state after you applied changes." - or something like that?

[jessegrosjean]

Yes, but I'm just in the middle of a mad summer dash, so won't get to it today, but will do.

[heckj]

Jesse - I'll go ahead and merge this and add the docs after.

[alexjg]

I think this is all good. I have a slightly uncomfortable feeling about the re-entrancy because we use an RwLock on the rust side to ensure exclusive access to the document and we panic if we can't obtain the lock because we know that on the Swift side we're ensuring exclusive access. However, I think the re-entrancy here would never happen when we're holding the lock on the Rust side so we're probably okay.

To make that concrete, here's put_in_map

    pub fn put_in_map(&self, obj: ObjId, key: String, value: ScalarValue) -> Result<(), DocError> {
        let obj = am::ObjId::from(obj);
        let mut doc = self.0.write().unwrap();
        assert_map(&*doc, &obj)?;
        doc.put(obj, key, value).map_err(|e| e.into())
    }

(self.0 is an RwLock<automerge::AutoCommit>)

You can see here that we panic if we can't obtain the lock (the self.0.write().unwrap() call). Now, none of the methods on Document return anything which refers to the document - and I don't think there is any way we could return such a reference as Uniffi won't let us - so we're okay. So, despite my uneasiness, I think this works.

[heckj]

On the Apple platforms side, NSRecursiveLock (the lock in question here) only allows the same thread to pass through the lock, so I think it prevents the bits where we'd get re-entrancy across multiple threads, and with a single thread access we'd be fine - it would come through to the Rust side as serialized calls to the llibrary since they're all coming from a single thread. Other lock implementations here could be very poor, so I'd want to not replace this with a "cheaper lock" down the road, as the different semantics could easily bite us, but this I think is going to be fine - a good choice for the pain point/use-case that Jesse's hitting.