Remove footnotes

[esthermmoturi]

Description

This PR seeks to close issue #509.

The transitions documentation
contained footnotes that not only made it confusing to read, but were not standard with the rest of the documentation format. To achieve uniformity and improve readability. This PR includes changes that have:

• Removed superscripts that were used as a reference to the footnote information provided within the page
• Converted the footnote reference to a collapsible paragraph as the information is detailed and optional to the readers)(serves as additional information)
• Fixed some grammatical errors
• Changed some heading/subheading levels to make right-hand navigation easier and neater.

Future recommendation for this page:

• The page has information overload and should be broken down and subdivided into various pages.

[jkuester]

Suggested change

	##### Configuration
	### Configuration

In standard markdown, I think usually you nest the headings so they get progressively smaller, but you generally do not skip a bunch of levels. Since multi_report_alerts is now an h2, I would have expected this to just be an h3. (Unless we have a reason for doing something different here...)

[jkuester]

Same goes for similar headings below.

[jkuester]

These docs are pretty tricky to begin with. I am afraid that just nesting the former footnotes into a details block is going to make things worse since it further fragments the relationships between all the information here. I have taken a stab at re-working these docs a bit to just de-normalize the info from the footnotes inline with the rest of the documentation. I have included some cross-referencing via deep-links. What do you think about something like this?

### Muting action 

Updates the target contact and all its descendants, setting the `muted` property equal to the current date in ISO format.

#### Client-side

*Added in 3.12.0*

Client-side muting runs offline on a user's device. Only the contacts and reports available on the device will be updated.

- Sets the `muted` property on the target contact and all its descendants to the device's current `date` (the moment the report is processed). 
- Adds/updates the [`muting_history` property]({{< ref "#client-side-muting-history" >}}) on every updated contact, to keep track of all the updates that have been processed client-side, as well as the last known server-side state of the contact and sets the `last_update` property to `client_side`
- Updates the report doc to add a `client_side_transitions` property to track which transitions have run client-side

#### Server-side

Server-side muting runs as a typical Sentinel transition. Contacts that are already in the correct state are skipped. This applies to updates to the contact itself, updates to the Sentinel `muting_history` and to the connected registrations (registrations of a contact that is already in the correct state will not be updated).

- Sets the `muted` property on the target contact and all its descendants to the moment Sentinel processed the muting action.
  - If the contact was already muted by a client, the `muted` date will be overwritten. The [client-side `muting_history`]({{< ref "#client-side-muting-history" >}}) will have a copy of the client-side muting date.
- Adds a [`muting_history` entry]({{< ref "#server-side-muting-history" >}}) to Sentinel `info` docs for every updated contact
- Updates all connected registrations (for the target contact and descendants), changing the state of all unsent `scheduled_tasks` to `muted`
  - Unsent `scheduled_tasks` have either a `scheduled` or `pending` state
- Updates the contact's client-side `muting_history` to set the `last_update` property to `server_side` and update the `server_side` section with the current date and muted state. 
- If the report was processed client-side, all "following" muting/unmuting events that have affected the same contacts will be replayed. This means the transition _could_ end up running multiple times over the same report. 
  - Replaying is required due to how PouchDB <-> CouchDB synchronization does not respect the order in which the documents have been created, to ensure that contacts end up in the correct muted state.

### Unmuting action

Updates the target contact's topmost muted ancestor and all its descendants, removing the `muted` property. Because the muted state is inherited, unmuting cascades upwards to the highest level muted ancestor. If none of the ancestors is muted, unmuting cascades downwards only.

#### Client-side

*Added in 3.12.0*

Client-side unmuting runs offline on a user's device. Only the contacts and reports available on the device will be updated.

- Adds/updates the [`muting_history` property]({{< ref "#client-side-muting-history" >}}) on every updated contact, sets the last known server-side state of the contact and sets the `last_update` property to `client_side`
- Updates the report doc to add a `client_side_transitions` property to track which transitions have run client-side

#### Server-side

Server-side unmuting runs as a typical Sentinel transition. Contacts that are already in the correct state are skipped. This applies to updates to the contact itself, updates to the Sentinel `muting_history` and to the connected registrations (registrations of a contact that is already in the correct state will not be updated).

- Adds a [`muting_history` entry]({{< ref "#server-side-muting-history" >}}) to Sentinel `info` docs for every updated contact
- Updates all connected registrations (for the target contact and descendants), changing the state of all present/future `scheduled_tasks` (ones due today or in the future) with the `muted` state to have the `scheduled` state.
  - All `scheduled_tasks` with a due date in the past will remain unchanged.
- Updates the contact's [client-side `muting_history`]({{< ref "#client-side-muting-history" >}}) to set the `last_update` property to `server_side` and update the `server_side` section with the current date and muted state.
- If the report was processed client-side, all "following" muting/unmuting events that have affected the same contacts will be replayed. This means the transition _could_ end up running multiple times over the same report.
  - Replaying is required due to how PouchDB <-> CouchDB synchronization does not respect the order in which the documents have been created, to ensure that contacts end up in the correct muted state.

### Muting history

#### Server-side muting history

Each time the `muted` state of a contact changes, an entry is added to a `muting_history` list saved in Sentinel `info` docs (stored as an array property with the same name).
Entries in `muting_history` contain the following information:

| Property | Description |
| --- | --- |
| muted | Boolean representing the muted state |
| date | Date in ISO Format |
| report_id | An `_id` reference to the report that triggered the action |


#### Client-side muting history

*Added in 3.12.0*

Each time the client changes the `muted` state of a contact, an entry is added to a `muting_history` property on the contact's doc. The `last_update` entry is also changed to `client_side`.
The `muting_history` property contains the following information:

| Property | Values | Description | 
| --- | ---- | ---- |
| last_update | `server_side` or `client_side` | Updated every time a service updates the contact, with the corresponding value | 
| server_side | Object |  |
| server_side.muted | `true` or `false` | Last known server-side muting state |
| server_side.date | Date in ISO format | Last known server-side muting/unmuting date | 
| client_side | Array | Client-side muting/unmuting events list. <br> New events are pushed at the end of this list and it should never be re-ordered. <br>The list represents the "chronological" order in which the reports that triggered muting were created. | 
| client_side[].muted | `true` or `false` | Client-side muting state | 
| client_side[].date | Date in ISO format | Client-side muting/unmuting date |
| client_side[].report_id | uuid | The uuid  of the muting/unmuting report that triggered the update |