git: Increase locking timeout for loose references

When trying to update references, Git will first try to acquire a lock and write the new value to this lockfile. As those locks may also be acquired by concurrently running processes it uses a timeout during which it will spin around the lock until it finally gets released. If Git fails to acquire the lock in time it aborts the transaction and returns an error.

We have recently bumped the timeout for acquiring the packed-refs lock to 1 second given that it is a shared resource that needs to be locked whenever deleting any reference. This new timeout value does not apply to loose references though, and that is on purpose: loose references only require fine-grained locking and thus don't have the same amount of lock contention as the packed-refs file.

But we have still observed locking issues here in production systems. During a storm of incoming RPC calls the system was heavily loaded. While there was some amount of contention around loose references, it still was comparatively limited. But given that:

- The system was heavily loaded and thus slowed down.

- The default loose reference locking timeout is only a 100
  milliseconds.

We saw thousands of WriteRef() RPC calls failing because of concurrently held locks.

Let's thus increase the timeout for loose references, as well. Given that the contention here should be much lower we don't go all the way to 10 seconds though, but instead only bump it to 1 second, which is the same 10-fold factor we have applied to the packed-refs locking timeout.

Changelog: fixed