release_notes/ocp-4-19-release-notes: Pick up Darragh's boot-image-clobber rewording

Pulling in the suggestion from [1], word for word (although I am
bumping the bug link to OCPBUGS-57796, now that that 4.19.z backport
tracker exists), to try to get something declared.  We can wordsmith
later if we want.  Personally, I have concerns, including:

> ... the boot image management overrides these customization images
> with boot images.

but "with boot images" doesn't make sense to me, because MachineSets
are going to reference boot images regardless; there's no "without
boot images" option.  The distinction is that sometimes the boot
images are specifically selected by the cluster admin, and the MCO's
boot image management would override those cluster-admin preferences.

> ...restore the boot images for the machine sets to their original
> location...

I'd prefer "previous value" or something to "original location".  I
haven't heard folks say "location" for an AMI ID or other MachineSet
property value, while I have heard "value" for that.  And it seems
like folks might confuse "original" as "what the MachineSet used when
it was created" when what we mean was "what the MachineSet used just
before the MCO clobbered its boot image value".

> ...delete any machines that were incorrectly generated by the
> overriding boot images.

I'd prefer "overriden boot images" or my "undesired boot images",
because the timeline there is:

1. MCO overrides the MachineSet's boot image configuration, inserting
   a stock boot image ID instead of the admin-preferred boot image ID.
2. Admin updates MachineConfiguration to disable MCO boot image
   management for that MachineSet.  After this, all overriding will be
   past-tense.  Cluster-admin preference for the admin-preferred boot
   image over the stock boot image can continue in the present-tense.
3. Admin restores MachineSet boot image ID configuration.
4. Admin deletes any Machines which launched from the stock boot
   image.

So I don't like the present-tense "overriding" in wording about step
(4).

It also feels weird to me to have:

> ...you can disable the boot image management feature...

as a non-link, with a later:

> To disable boot image management, see
> ref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[disable
> boot image management].

giving the link.  I'd have expected some of the folks reading the
initial words to think "huh, how do I do this step?", and having the
words they were wondering about be the link to the docs that would
clear them up seems more usable than requiring them to skim to the end
of the paragraph to find the link they need.  But maybe there are doc
conventions around this whose motivation I don't understand?

Anyhow, none of my concerns seem large enough to be worth delaying a
known-issue declaration over, so I'm adopting Darragh's wording in
this commit, pointing out the places I don't agree with in this commit
message, and leaving it up to the docs folks to decide if any of my
concerns are worth further word-smithing in future pull requests.

[1]: #94987 (comment)

Author: wking

release_notes/ocp-4-19-release-notes.adoc

@@ -2741,7 +2741,7 @@ In the following tables, features are marked with the following statuses:
 
 * In {product-title} {product-version}, clusters using IPsec for network encryption might experience intermittent loss of pod-to-pod connectivity. This prevents some pods on certain nodes from reaching services on other nodes, resulting in connection timeouts. Internal testing could not reproduce this issue on clusters with 120 nodes or less. There is no workaround for this issue. (link:https://issues.redhat.com/browse/OCPBUGS-55453[OCPBUGS-55453])
 
-* {product-title} clusters that are installed on {aws-short} with custom AMIs or on {gcp-short} with custom disk images will have those customizations overridden by boot image management. To recover, you must xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[disable boot image management], restore your MachineSet boot images, and delete any Machines created with an undesired boot image. (link:https://issues.redhat.com/browse/OCPBUGS-57796[OCPBUGS-57796])
+* If you install a cluster on {aws-short} that has Amazon Machine Images (AMI) enabled or on  {gcp-short} that has custom disk images enabled, the boot image management overrides these customization images with boot images.  As a workaround, you can disable the boot image management feature, restore the boot images for the machine sets to their original location, and delete any machines that were incorrectly generated by the overriding boot images. To disable boot image management, see ref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[disable boot image management]. (link:https://issues.redhat.com/browse/OCPBUGS-57796[OCPBUGS-57796])
 
 * {product-title} clusters that are installed on {aws-short} in the Mexico Central region, `mx-central-1`, cannot be destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-56020[OCPBUGS-56020])