chore: Rewrap Gateway DefaultScope comments and make generate

Signed-off-by: Flynn <[email protected]>

Author: kflynn

apis/v1/gateway_types.go

@@ -295,25 +295,25 @@ type GatewaySpec struct {
 	// <gateway:experimental>
 	TLS *GatewayTLSConfig `json:"tls,omitempty"`
 
-	// DefaultScope when set configures the Gateway as a default Gateway, meaning
-	// it will dynamically and implicitly have Routes (e.g. HTTPRoute) attached
-	// to it, according to the scope configured here.
-	//
-	// If unset or set to the empty string `""` (the default), the Gateway will not
-	// act as a default Gateway; if set, the Gateway will claim any Route with a
-	// matching scope set in its UseDefaultGateway field, subject to the usual
-	// rules about which routes the Gateway can attach to.
-	//
-	// Think carefully before using this functionality! While the normal rules about
-	// which Route can apply are still enforced, it is simply easier for the wrong
-	// Route to be accidentally attached to this Gateway in this configuration. If the
-	// Gateway operator is not also the operator in control of the scope (e.g.
-	// namespace) with tight controls and checks on what kind of workloads and
-	// Routes get added in that scope, we strongly recommend not using this just
-	// because it seems convenient, and instead stick to explicit Route attachment.
-	//
-	// +optional
-	// <gateway:experimental>
+	// DefaultScope, when set, configures the Gateway as a default Gateway,
+	// meaning it will dynamically and implicitly have Routes (e.g. HTTPRoute)
+	// attached to it, according to the scope configured here.
+	//
+	// If unset or set to the empty string `""` (the default), the Gateway
+	// will not act as a default Gateway; if set, the Gateway will claim any
+	// Route with a matching scope set in its UseDefaultGateway field, subject
+	// to the usual rules about which routes the Gateway can attach to.
+	//
+	// Think carefully before using this functionality! While the normal rules
+	// about which Route can apply are still enforced, it is simply easier for
+	// the wrong Route to be accidentally attached to this Gateway in this
+	// configuration. If the Gateway operator is not also the operator in
+	// control of the scope (e.g. namespace) with tight controls and checks on
+	// what kind of workloads and Routes get added in that scope, we strongly
+	// recommend not using this just because it seems convenient, and instead
+	// stick to explicit Route attachment.
+	//
+	// +optional <gateway:experimental>
 	DefaultScope GatewayDefaultScope `json:"defaultScope,omitempty"`
 }