r/consensus: add election lock

will be used later to guard from concurrent elections

src/v/raft/consensus.cc

@@ -286,6 +286,7 @@ ss::future<xshard_transfer_state> consensus::stop() {
     co_await _append_requests_buffer.stop();
     co_await _batcher.stop();
 
+    _election_lock.broken();
     _op_lock.broken();
     _deferred_flusher.cancel();
     co_await _bg.close();

src/v/raft/consensus.h

@@ -846,15 +846,22 @@ class consensus {
     /// used to wait for background ops before shutting down
     ss::gate _bg;
 
+    /**
+     * Locks listed in the order of nestedness, election being the outermost
+     * and snapshot the innermost. I.e. if any of these locks are used at the
+     * same time, they should be acquired in the listed order and released in
+     * reverse order.
+     */
+    /// guards from concurrent election where this instance is a candidate
+    mutex _election_lock{"consensus::election_lock"};
     /// all raft operations must happen exclusively since the common case
     /// is for the operation to touch the disk
     mutex _op_lock{"consensus::op_lock"};
     /// since snapshot state is orthogonal to raft state when writing snapshot
     /// it is enough to grab the snapshot mutex, there is no need to keep
-    /// oplock, if the two locks are expected to be acquired at the same time
-    /// the snapshot lock should always be an internal (taken after the
-    /// _op_lock)
+    /// oplock
     mutex _snapshot_lock{"consensus::snapshot_lock"};
+
     /// used for notifying when commits happened to log
     event_manager _event_manager;
     std::unique_ptr<probe> _probe;