Previously, if the client was disconnected while the initial worktree
state was being sent, it would not see the remaining state after reconnecting.
This was due to `scan_id` and `completed_scan_id` both being initialized to
`0`, so the client would ask for updates since `0` and get nothing.

This commit changes the worktree to initialize `scan_id` to `1` and
`completed_scan_id` to `0`, so that we get the full worktree again on reconnect.

Previously, we would only cancel pending calls when the room became
empty.

Previously, dropping a oneshot sender didn't wake the receiver.

In the case of Github release deserialize error, log response text

Co-Authored-By: Joseph Lyons <joseph@zed.dev>

Previously, because UpdateProject messages were sent in a separately-
spawned task, they could be sent after CreateBufferForPeer messages that
were intended to be sent after them.

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

The host will send a `SaveBuffer` message anyway and this prevents re-querying
the database, which could cause two `BufferSaved` messages to race and, as a
result, cause guest to apply them in the wrong order.

Don't panic if worktree was dropped before sending path changes

In `refresh_entry`, we send a message to the `self.path_changes_tx` channel
to notify the background thread that a path has changed. However, given that
`refresh_entry` uses `spawn_weak`, the worktree could get dropped before sending
the message, which could cause a panic.

This commit changes the code to return an error instead of panicking.

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

Don't export platform::* from gpui

I'd like to avoid cluttering the top-level namespace with all the platform-
specific types.

Put backtrace on a new line when reporting panics

Update copy path commands

Merge MutableAppContext into AppContext

There may have been a good reason for the difference at some point, or I was
still learning Rust. But now it's just &mut AppContext vs &AppContext.

Check if the buffer already exists *before* overwriting it.
Ignore redundant registrations on remote projects.

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

Add close items to left and right

This ensures that two successive file updates coming from the host are
not applied in reverse order.

Increase git diff gutter width slightly

Previously, if the test panicked before it had a chance to fully
apply an operation, it would end up not being saved in the plan.
With this commit we will mark the operation as applied before we
start processing it, and mark it as not applied if, once we're done,
we've found out that it couldn't be applied. This is consistent with
what we do for client operations.

This fixes a bug where the host would momentarily disconnect and the guest
would close and reopen the project. This would cause the host to not observe
the guest closing the project. When the guest tried to open one of the
buffers opened prior to closing the project, the host would not send them the
buffer state because it would still remember that the buffer was shared.

The `shared_buffers` map is now cleared when the host reconnects and will slowly
get re-filled as guests issue `SynchronizeBuffers` requests.