Re: [PATCH 06/11] apply: move lockfile into `apply_state`

> We have two users of `struct apply_state` and the related functionality
> in apply.c. Each user sets up its `apply_state` by handing over a
> pointer to its static `lock_file`. (Before 076aa2cbd (tempfile:
> auto-allocate tempfiles on heap, 2017-09-05), we could never free
> lockfiles, so making them static was a reasonable approach.)
> 
> Other than that, they never directly access their `lock_file`s, which
> are instead handled by the functionality in apply.c.
> 
> To make life easier for the caller and to make it less tempting for a
> future caller to mess with the lock, make apply.c fully responsible for
> setting up the `lock_file`. As mentioned above, it is now safe to free a
> `lock_file`, so we can make the `struct apply_state` contain an actual
> `struct lock_file` instead of a pointer to one.
> 
> The user in builtin/apply.c is rather simple. For builtin/am.c, we might
> worry that the lock state is actually meant to be inherited across
> calls. But the lock is only taken as `apply_all_patches()` executes, and
> code inspection shows that it will always be released.
> 
> Alternatively, we can observe that the lock itself is never queried
> directly. When we decide whether we should lock, we check a related
> variable `newfd`. That variable is not inherited, so from the point of
> view of apply.c, the state machine really is reset with each call to
> `init_apply_state()`. (It would be a bug if `newfd` and the lock status
> were not in sync. The duplication of information in `newfd` and the lock
> will be addressed in the next patch.)