XEP-0280: Remove the removal of the `<private/>` element

The requirement to strip `<private/>` by the sending server was in the
XEP from day 1. It was later changed from "MUST" to "SHOULD" and from
"sending server" to "receiving server", so that the latter could also
prevent normal message routing.

As this behavior only ever affected the `<private/>` element and not the
`<no-copy/>` hint (introduced in 2017), which should be treated in a
similar but not equal way, and there is a security benefit in letting
the receiving client know that message routing was manipulated, it makes
sense to remove this requirement.

As there is no negative effect of keeping another element in delivered
messages, nobody complained about `<no-copy/>` not being stripped, and
bumping Carbons today would be rather unfortunate, this is done without
a namespace bump, despite "breaking" the specification.

xep-0280.xml

@@ -466,9 +466,9 @@
     <li> The sending client MAY exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, by adding a &lt;private/&gt; element qualified by the namespace "urn:xmpp:carbons:2" and a &lt;no-copy/&gt; hint as described in &xep0334; as child elements of the &MESSAGE; stanza.</li>
     <li>The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender.</li>
     <li>The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient,</li>
-    <li>and the receiving server SHOULD remove the &lt;private/&gt; element before delivering to the recipient.</li>
   </ul>
 
+  <p>Interoperability note: earlier versions of this XEP required or recommended the removal of the &lt;private/&gt; element (albeit not of the &lt;no-copy/&gt; hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.</p>
   <p><strong>Note:</strong>
     Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect.
     If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p>