Make tests Nightly instead of Slow

Author: paulirwin

src/Lucene.Net.Tests.Analysis.Common/Support/Analysis/Util/TestOpenStringBuilderBufferWriter.cs

@@ -302,7 +302,7 @@ public void GetMemory_InitSizeCtor_WithSizeHint(int sizeHint)
         // LUCENENET specific: This test allocates a very large buffer to verify that Advance()
         // performs its bounds check purely arithmetically (m_len vs. m_buf.Length); Advance() itself
         // never touches buffer memory, and WriteData only touches the first 1,000 chars. If the
-        // allocation fails with OutOfMemoryException, the test is a no-op. Marked [Slow] due to the
+        // allocation fails with OutOfMemoryException, the test is a no-op. Marked [Nightly] due to the
         // large allocation.
         //
         // NOTE: The upstream ArrayBufferWriter test gated this on Windows/macOS, and so do we. The
@@ -311,7 +311,7 @@ public void GetMemory_InitSizeCtor_WithSizeHint(int sizeHint)
         // zero-initialization of the array touches every page, which can invoke the OOM killer (an
         // uncatchable SIGKILL, not an OutOfMemoryException) and tear down the whole test run.
         [Test]
-        [Slow]
+        [Nightly]
         public void InvalidAdvance_Large()
         {
             // LUCENENET specific: skip on Linux (see note above); the large allocation can be killed

src/Lucene.Net.Tests/Support/Analysis/TokenAttributes/TestCharTermAttributeImplBufferWriter.cs

@@ -248,15 +248,15 @@ public void GetMemory_ExceedMaximumBufferSize_WithSmallStartingSize()
         // performs its bounds check purely arithmetically (termLength vs. termBuffer.Length);
         // Advance() itself never touches buffer memory, and WriteData only touches the first 1,000
         // chars. If the allocation fails with OutOfMemoryException, the test is a no-op. Marked
-        // [Slow] due to the large allocation.
+        // [Nightly] due to the large allocation.
         //
         // NOTE: The upstream ArrayBufferWriter test gated this on Windows/macOS, and so do we. The
         // risk is real on Linux but comes from the allocation itself, not from Advance(): under memory
         // overcommit the kernel may grant the large buffer optimistically, then the GC's
         // zero-initialization of the array touches every page, which can invoke the OOM killer (an
         // uncatchable SIGKILL, not an OutOfMemoryException) and tear down the whole test run.
         [Test]
-        [Slow]
+        [Nightly]
         public void InvalidAdvance_Large()
         {
             // LUCENENET specific: skip on Linux (see note above); the large allocation can be killed