Move graphical vnc console interface to retired status

Consensus from discussion in IRC represents a forward direction
on the graphical console modeling.

A few distinct aspects which drives this consensus:

1) The existing specification defines a fairly heavy weight/design
   intensive modeling which was based on an attempt to create a
   specific delineation, between "console" and "graphical console",
   where console was explicitly "serial console".
2) Except, drivers, including out of tree patches could always just
   respond to the console creation request with a VNC url. Julia
   Kreger has indicated she was aware of a HPE patch from her time
   at HPE where Helion OpenStack did exactly this to integrate with
   Nova's framework.
3) Serial consoles are sort of on their way out of vouge. What we
   mean by this the dual challenge of evolution of architecture,
   combined with a lack of evolution due to low level designs.
   UEFI specifically is modeled around graphical interactions,
   which largely started from the hardware vendors wanting logos
   and "graphical" boot splash screens. At the same time, serial
   consoles continue to leveral low level interrupt which we've
   since observed issues with serial console interaction resulting
   in detrimental performance impact due to the interrupts being
   triggered with general console output. Comparing interaction
   with a graphics card, the OS kernel generally just writes to
   an IO address without triggering interrupts.
4) The base interaction with nova and users *really* doesn't *need*
   to change, and the existing serial console functionality, while
   needing a *ton* of work does work for some operators, be it a
   port to connect to, or a webpage to load from the console
   activation interaction.

Where this leaves Ironic, is we likely need to figure out
*exactly* what we need to do on the lower level for *redfish*
and unlock ourselves to do so. This action sort of allows us to
do that, focus on the lower level challenge instead of focusing
on creating an entirely new design that is not really needed *aside*
from resolving the ambiguity we've created for ourselves. Partly
which this change does help work towards resolving as a first step.

Also see: https://meetings.opendev.org/irclogs/%23openstack-ironic/%23openstack-ironic.2024-11-01.log.html
Change-Id: Idb86ac9f7e27b4fe4b73f6163da81b743517adef

Change-Id: I6527458dbd28d8de6b86a406392b219a1a7c31d1

specs/not-implemented/vnc-graphical-console.rst

@@ -1 +0,0 @@
-../approved/vnc-graphical-console.rst

specs/retired/vnc-graphical-console.rst

@@ -15,6 +15,18 @@ graphical console. This proposal presents the work required to create a new
 driver interface for accessing graphical console of a node.
 
 
+.. NOTE::
+   This specification has been retired. This was done based upon community
+   consensus on several aspects of the design. Primarily, in that the existing
+   console interface can serve both serial consoles and graphical consoles
+   without the overhead and operator confusion induced through yet another
+   different interface to set. From a secondary aspect, serial console use
+   and interaction has fallen from favor since this feature was designed,
+   specifically in part due to move to UEFI firmware and the overall modeling
+   of serial ports in modern hardware, as a primary output driven by CPU
+   interrupt triggering, which can have detrimental performance impacts on
+   running workloads.
+
 Problem description
 ===================