kernel-interface: Change reqid if seq. nos. are supported and narrowing occurred

With the sequence numbers we don't have to maintain the reqid to delete
the temporary state.

One exception is with labels.  There we currently only install trap
policies with the generic label.  SAs created from those don't have
policies installed, so we have to reuse the reqid of the trap even if
narrowing occurs.

And as before, we reuse the reqid without checking traffic selectors if
sequence numbers are not supported.

Note that if a CHILD_SA is manually initiated (i.e. has no sequence
number assigned) right before an acquire is triggered, there are several
possible outcomes depending on whether narrowing occurs.  If there is no
narrowing, the same reqid is assigned and the kernel will remove the
temporary SA when the SA is installed (no seq => reqid match).
Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire
state in the trap manager gets removed.  If there is narrowing, a new
reqid is allocated, so the installation of the SA will not remove the
temporary state.  However, due to the narrowing, the duplicate check
fails and when the duplicate is installed (with sequence number), the
temporary state is deleted (as is the state in the trap manager).

src/libcharon/kernel/kernel_interface.c

@@ -392,12 +392,19 @@ METHOD(kernel_interface_t, alloc_reqid, status_t,
 		/* search by reqid if given */
 		entry = this->reqids->get(this->reqids, tmpl);
 	}
-	if (entry && entry_equals_selectors(entry, tmpl))
+
+	/* if the IPsec stack supports sequence numbers for acquires, we can
+	 * allocate a new reqid if narrowing occurred (otherwise, we get the same
+	 * reqid back anyway).  if not, we want to reuse the existing reqid of
+	 * the trap polices and explicitly don't want to match the traffic
+	 * selectors.  another case where we want to reuse an existing reqid is
+	 * when labels are used.  because we currently only install policies once
+	 * with the generic label, the reqid has to stay the same even if narrowing
+	 * occurs.  however, in either case we don't want to reuse the reqid if the
+	 * additional selectors (e.g. marks) are different */
+	if (entry && (label || !(get_features(this) & KERNEL_ACQUIRE_SEQ)) &&
+		entry_equals_selectors(entry, tmpl))
 	{
-		/* we don't require a traffic selector match for existing reqids,
-		 * as we want to reuse a reqid for trap-triggered policies that
-		 * got narrowed during negotiation, but we don't want to reuse the
-		 * reqid if the additional selectors (e.g. marks) are different */
 		reqid_entry_destroy(tmpl);
 	}
 	else