title: Ejabberd MucSub issue with room leave/exit
body: <p>we are working on an Instant Messaging app based on XMPP handling members-only persistent groups using XEP-0045 and MucSub.
  We have some issues with room occupancy and we didn't find a way to let users abandon a room permanently: we tried several approaches and none of them led to successful behavior.</p>
  <p>The behavior we are looking for is very similar to WhatsApp and other similar mobile apps.</p>
  <p>The first thing we had to think about is: which users we consider as participants?</p>
  <p><strong>The parameters we can use are:</strong></p>
  <ul>
  <li>Affiliation</li>
  <li>Role</li>
  <li>Subscription</li>
  </ul>
  <p><strong>To consider it as a working solution, we need that:</strong></p>
  <ul>
  <li>All the standard and obvious features of group conversations</li>
  <li>Members can join and leave the group</li>
  <li>If a member leaves a group, he cannot rejoin without invitation</li>
  <li>Members can see the list of members and their privileges</li>
  <li>Membership should not be affected by the member’s connection status</li>
  <li>The member list and privileges must be persistent across server reboots</li>
  </ul>
  <p><strong>Our test environment:</strong></p>
  <ul>
  <li>Ejabberd 19.09 with mucsub enabled</li>
  <li>PostgreSQL DB</li>
  </ul>
  <p>We explored the following approaches:</p>
  <h1>Approach 1:</h1>
  <p>We can use affiliation to determine if a user is a participant, and consider him as a non-participant when the affiliation is none, outcast or not affiliated.</p>
  <p><strong>Who we consider as a participant:</strong></p>
  <ul>
  <li>Affiliation: member (or owner or admin)</li>
  <li>Role: any</li>
  <li>Subscription: any</li>
  </ul>
  <p><strong>How to abandon a room:</strong></p>
  <p>a. Sending a presence unavailable</p>
  <pre class="lang-xml prettyprint-override"><code>
      &lt;presence to='roomX@conference.x.com/test2' from='test2@x.com' type='unavailable'&gt;
        &lt;status&gt;leave&lt;/status&gt;
      &lt;/presence&gt;
  
  </code></pre>
  <p>b. changing your own affiliation</p>
  <pre class="lang-xml prettyprint-override"><code>
      &lt;iq from='test2@x.com/app' 
          id='1234' 
          to='roomX@conference.x.com'
          type='set'&gt;
        &lt;query xmlns='http://jabber.org/protocol/muc#admin'&gt;
          &lt;item affiliation='none' jid='test2@x.com'/&gt;
        &lt;/query&gt;
      &lt;/iq&gt;
  
  </code></pre>
  <p><strong>New attributes of ex participants:</strong></p>
  <ul>
  <li>Affiliation: none (or outcast if the user has been banned)</li>
  <li>Role: any</li>
  <li>Subscription: any (more probably the user will be unsubscribed, but this parameter is not checked to determine participants)</li>
  </ul>
  <p><strong>Issues:</strong></p>
  <ul>
  <li>Sending a presence unavailable is not affecting the affiliation. (It’s not reflecting anywhere in the DB)</li>
  <li>Sending a presence unavailable sometimes does not obtain a response from the server (related issue opened here: <a href="https://stackoverflow.com/q/59379471/3623530">Ejabberd MucSub: When a member sends a presence unavailable, the service does not respond</a>)</li>
  <li>Setting an affiliation for yourself does not work (as per specs: only admins can change affiliations)</li>
  </ul>
  <h2> Approach 2:</h2>
  <p>We can use subscriptions status to determine if a user is a participant, and consider him as a non-participant when the he unsubscribes.</p>
  <p><strong>Who we consider as a participant:</strong></p>
  <ul>
  <li>Affiliation: member (or owner or admin)</li>
  <li>Role: any</li>
  <li>Subscription: subscribed to all kind of events</li>
  </ul>
  <p><strong>How to abandon a room:</strong></p>
  <ul>
  <li>The user will abandon a room by unsubscribing.</li>
  </ul>
  <pre class="lang-xml prettyprint-override"><code>
  &lt;iq from='test2@x.com'
      to='roomX@conference.x.com'
      type='set'
      id='12345'&gt;
    &lt;unsubscribe xmlns='urn:xmpp:mucsub:0' /&gt;
  &lt;/iq&gt;
  
  </code></pre>
  <p><strong>New attributes of ex participants:</strong></p>
  <ul>
  <li>Affiliation: member (or owner or admin)</li>
  <li>Role: any</li>
  <li>Subscription: not subscribed</li>
  </ul>
  <p><strong>Issues:</strong></p>
  <ul>
  <li>The ex participant can rejoin subscribe again without invitation, and following this approach will lead that he will be considered as a participant again (with no invitation)</li>
  </ul>