fix late acquire

Although it has no practical impact on the processor (except if
`addBlock` were cancelled, which it never is), the `acquire` should be
outside the `finally` (since obvisouly, if it were cancelled it will not
be acquired and therefore shouldn't be released)

Author: arnetheduck

beacon_chain/gossip_processing/block_processor.nim

@@ -755,18 +755,19 @@ proc addBlock*(
     return self[].storeBackfillBlock(blck, sidecarsOpt)
 
   let queueTick = Moment.now()
+
+  # If the lock is acquired already, the current block will be put on hold
+  # meaning that we'll form an unbounded queue of blocks to be processed
+  # waiting for the lock - this is similar to using an `AsyncQueue` but
+  # without the copying and transition to/from `Forked`.
+  # The lock is important to ensure that we don't process blocks out-of-order
+  # which both would upset the `storeBlock` logic and cause unnecessary
+  # quarantine traffic.
+  self.pendingStores += 1
+  await self.storeLock.acquire()
+
   let res =
     try:
-      # If the lock is acquired already, the current block will be put on hold
-      # meaning that we'll form an unbounded queue of blocks to be processed
-      # waiting for the lock - this is similar to using an `AsyncQueue` but
-      # without the copying and transition to/from `Forked`.
-      # The lock is important to ensure that we don't process blocks out-of-order
-      # which both would upset the `storeBlock` logic and cause unnecessary
-      # quarantine traffic.
-      self.pendingStores += 1
-      await self.storeLock.acquire()
-
       # Cooperative concurrency: one block per loop iteration - because
       # we run both networking and CPU-heavy things like block processing
       # on the same thread, we need to make sure that there is steady progress