During file copy-based initial sync, we have this _killBackupCursor method that first checks if we know of an active initial sync backup cursor, and kills that cursor if we do. We call this during shutdown and before starting initial sync. But we "fire and forget" the kill cursor command, which introduces a race condition where we can complete shutdown before the command actually reaches the sync source. This is a problem because the sync source does not allow two backup cursors to exist simultaneously; the old one must be killed. However, since the kill cursor command didn't reach the sync source before the node shut down (and since the node has no "memory" of the previous backup cursor in the prior FCBIS run), it'll enter a crash-loop where it keeps retrying initial sync and failing because of the dangling cursor.

Some questions:

1) Should/can we await the response of the kill-cursor command during shutdown?
2) Trying to kill a backup cursor and passing in the wrong cursor UUID will fail and return the correct UUID of the active backup cursor, if there is one. Can we safely assume that, if there is a backup cursor when we start FCBIS, it's from a previous failed FCBIS run and we're allowed to kill it?
3) If so, should we try to kill the active backup cursor on every FCBIS run, or only when we detect the "existing backup cursor" error?