Wiriting cdef extension classes for `Future` objects for speeding up `_SyncSocketReaderFuture` and `_SyncSocketWriterFuture`

I have been brainstorming ways of going about optimizing some objects in uvloop and winloop's code and I think I have an idea for making these
objects run slightly faster and I was wondering if I could make the same optimizations on uvloop's end when I am done implementing this on winloop's side. My main objective involves wrapping _SyncSocketReaderFuture and _SyncSocketWriterFuture to a faster object such as a cdef extension so that these can be more optimized as well as possibly looking into getting rid of aio_Future if proven to be faster since programmers should rely on what asyncio.isfuture does and not isinstance(fut, asyncio.Future) which should be discouraged allowing for new optimizations to be introduced.

The other workaround idea was asking cpython for a CAPI Capsule which I wrote an issue for already but I think if this idea is proven successful we can skip that entirely and use this instead.

# My concept is still a little incomplete so take this with a grain of salt.

cimport cython
from .loop cimport Loop # Ignore for now I am just needing this since I am working with cyright in vscode to help with my thinking process.
import sys
from cpython.exc cimport PyErr_SetString, PyErr_SetObject
from cpython.ref cimport Py_CLEAR
from cpython.object cimport PyObject
from cpython.list cimport PyList_GET_SIZE, PyList_Append
from cpython.tuple cimport PyTuple_GET_ITEM
from cpython.contextvars cimport PyContext_CopyCurrent
from asyncio import format_helpers


include "includes/stdlib.pxi"

# In CPython these are enums so lets make some enums
# to get off from strings for speed.
cdef enum fut_state:
    STATE_PENDING = 0
    STATE_CANCELLED = 1
    STATE_FINISHED = 2

cdef extern from "Python.h":
    """
#define PyObject_isNULL(obj) obj == NULL
#define DoTheEvilTrick(obj, to) \\
    to = obj; obj = NULL
    """
    # Checks to see if PyObject* is null by as a normal object
    # without recasting itself.
    bint PyObject_isNULL(object obj)
    # Don't let cython toy with refs...
    void DoTheEvilTrick(object obj, object to)

    int PyException_SetTraceback(object ex, object tb) except -1
    object PyException_GetContext(object ex)
    void PyException_SetContext(object ex, object ctx)
    object PyException_GetCause(object ex)
    void PyException_SetCause(object ex, object cause)
    object PyException_GetTraceback(object ex)


	
# Here is a comptable version of asyncio.Future forked over from
# python 3.15 which is currently in research mode but 
# we can make changes if needed.

# I'll mix a bit of CPython in so that we can be speedy.

cdef class Future:
    """This class is *almost* compatible with concurrent.futures.Future.

    Differences:

    - This class is not thread-safe.

    - result() and exception() do not take a timeout argument and
      raise an exception when the future isn't done yet.

    - Callbacks registered with add_done_callback() are always called
      via the event loop's call_soon().

    - This class is not compatible with the wait() and as_completed()
      methods in the concurrent.futures package.

    """
    
    cdef:
        # obviously since we don't want this exposed for external editing.
        Loop fut_loop
        # Skipping fut_context0 and fut_callback0 to prevent
        # complexity we can optimize further later...
        list fut_callbacks    
        object fut_exception  
        object fut_exception_tb
        object fut_result
        object fut_source_tb    
        object fut_cancel_msg 
        object fut_cancelled_exc
        object fut_awaited_by
        fut_state fut_state

        bint fut_awaited_by_is_set
        bint fut_is_task
        unsigned int fut_log_tb
        unsigned int fut_blocking

The proposal targets _SyncSocketReaderFuture and _SyncSocketWriterFuture and suggests replacing or removing aio_Future with a Cython extension class. No repository file, test, benchmark, or concrete acceptance criteria is named, so start by locating those future implementations and their asyncio.isfuture consumers. Done would require a demonstrated speedup while preserving the expected Future behavior, but the issue does not define how that should be measured.