[glpatcern]

Inspired by @MahdiBaghbani

The suggested change is two-fold:

• rename the notification to CONTACT_REMOVED, to reflect the fact that it typically applies to a single pair
• tell apart two possible scenarios with an additional, optional property

For the two scenarios, consider an initial state as follows:

• Server A: user Alice has {Bob@B, Betty@B} as federated contacts
• Server B: user Bob has Alice@A; user Betty has Alice@A

Scenario 1. Alice stops collaborating with Bob.
A sends to B:

{
	"notificationType": "CONTACT_REMOVED"
	"shareType": "user"
	"message": "Alice has stopped collaborating with Bob"
	"user": {
		"userId": "alice@A"
		"localUserId": "bob@B"
	}
}

=> B drops alice@A from Bob's contacts list only.

Scenario 2. Alice quits A's organization.
A sends to B:

{
	"notificationType": "CONTACT_REMOVED"
	"shareType": "user"
	"message": "Alice has left"
	"user": {
		"userId": "alice@A"
	}
}

=> B drops Alice from all users' list, i.e. Bob's and Betty's.