To simplify the subscription logic, this PR aims at removing the
subscription's stage model and anything that depends on it to replace
if by a simpler selection field called `subscription_state`.

This field will merge the usage of the follwing fields :
 -stage_id
 -stage_category
 -subscription_management
 -renew_state

For clarity sake's these fields are now represented by the 7
state of `subscription_state` :
 -'Quotation', Quotation for a new subscription
 -'Renewal Quotation', Renewal Quotation for existing subscription
 -'In Progress', Active Subscription or confirmed renewal for active subscription
 -'Paused', Active subscription with paused invoicing
 -'Renewed', Active or ended subscription that has been renewed
 -'Churned', Closed or ended subscription
 -'Upsell', Quotation or SO upselling a subscription,
    upsells are not subscriptions

Following theses changes, massive overhaul have been made
to the different subscription views to enhance the
usability as well as the onboarding of this app.
One of the main focus of these change was to make
the subscription view more closely act like the sale's
view.

Additionally, the old `to_renew` behaviour has been removed
as it wasn't fitting the new plan for subscription and will
be replaced in the future.

task-id : 3190077

Purpose
=======

Articles that need to be shared with multiple persons will most probably
quickly end up being set in the workspace so that no further member update
is required.

As a consequence, we need a way to allow users to pick what is displayed in
their rightbar so that it is not crammed with root articles they'll never
click on.

Especially needed on crowded databases where each departments has many root
articles one does not actually need.

Specs
=====

We introduce the notion of `Visibility` for articles. The visibility of an
article is the fact whether or not the article will be listed in the hierarchy
tree (in the left panel of the knowledge main view). This does not modify the
access rights on those articles!

An article can be configured to be visible for *Everyone* or *For members only*.
When the visibility is set to:
* *Everyone*, every internal user is able to see the article without
  doing anything.
* *Members*, the users cannot see the article if they're not a member of the
  article.

To minimise DB impact, a boolean field has been added to reflect this :
`is_article_visible_by_everyone`. (If not, the article is visible for members
only)

Also, a new user dependant computed field as been added: `is_article_visible`.
An article is visible for a user if:
The user has access to it
AND
    the visibility of the article is set to Everyone
    OR
    The user is member of this article (if article visibility = member Only)

A hidden article is still available for every user that can access it.
The 'standard' quick search does not display the hidden articles but
an hidden mode has been added to the palette to specifically search for them.
Hidden article can be accessible via the Search methods (quick search in hidden
mode / search in the tree view) or via direct links.

This feature is only meant for internal users, to trim their tree to what
is necessary to them. Share users already have a limited amount of
accessible articles. This visibility concept is then not necessary for them.

Performance notes:

We are also increasing the query counter of three performance tests because,
since we have two computed field, we have more queries to do when opening
a record and when moving an article.

Those increases in the number of queries comes from the fields: `user_can_see`
and `everyone_can_see`, plus the addition of a member when creating an article
triggers an additional query for the access.

Use Cases
=========

The usage of Visibility is quite complex and maybe better understood with
some 2 use cases, 1 simple and 1 more complex:

Use Case 1
==========
You hide articles that you can see inside of a hidden root to cleanup the
sidebar. This is useful for articles you do not want to see everyday such as
FAQs or less useful informations that could be interesting for a few selection
of people. (LAN Parties, Tennis Team, Band Practice, etc.)

Step 1
======

You create 3 Articles called *Root*, *Parent* and *Child* : when creating them,
their visibility is set to **Members**, they are thus only visible to members
of the articles including yourselves. (You are directly added as a Member of
the article when setting the Visibility to **Members**)

Step 2
======

You remove yourselves from *Root*, to hide it for you, and move the other 2
below it with the Move To option. This way all the articles are hidden for you
in the sidebar but you can easily search *Parent* and *Root* via the command
palette, since you can see them. (You are a member of these articles after all)

But you won't see *Root* using the classic search since you are not a member of
this article.

Use Case 2
==========

You create root articles corresponding to teams of people or departments.

Step 1
======

You create multiple articles for each of the teams in your enterprise: R&D,
Sales, Accounting, etc. and you create an article visible by all (e.g. HR FAQ).

Step 2
======

For each team you add children articles and adds all the corresponding members
for each department/team.

Step 3
======

When being connected as a user, member of the R&D team, you see that you don't
have the R&D root into the sidebar.
You can search for it using the advanced search either by typing **$** in the
classic search, or by using the button launching the search for hidden articles
and you open the R&D root.

Step 4
======

You can navigate inside of the hidden structure before joining the root as a
member in order for you to see it in your sidebar.

==

task-2900465