This commit enables user to login with their Microsoft Account.

We have used implicit type authentication for all other providers,
which directly gives access_token for fetching user details.

However, to implement implicit type auth in case of Microsoft, an
extra parameter 'nonce' needs to be passed in the request to fetch
the access_token and id_token (id_token is used for fetching basic
user details). Here 'nonce', should be a randomized value which can
be verified in response to mitigate token replay attacks, and thus
have to be stored somewhere if we want to verify it.

Also, instead of using implicit type auth, it is recommended for
web-apps to use Authorization Code Grant flow for authentication,
which is more secure than the former one.

For both above reasons, this commit makes it possible to use the
Authorization Code Grant flow for all providers, and uses it
by default for Microsoft Azure.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


PS : I used this PR https://github.com/odoo/odoo/pull/29180

thanks @dep-odoo 

@odony @antonylesuisse Any customers ask to have this feature in Odoo.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Purpose
=======

Allow companies to centralize all their knowledge in a specific place they own.
Create wiki-like pages to structure the information and make it easily
available. Leverage those later on while working in the back-end.

Specifications
==============

Articles will be classified in 3 categories:
- Workspace: The articles are available for each base users in read access.
Only knowledge users can create, read, modify and delete knowledge articles.
- Private: The articles are only available for the owner. Only knowledge users
can set an article as private.
A private article can be shared to anyone in read access only
This last point will be done in a later commit.
- Favourite: Some articles, Private or in Workspace, can be set as favourite and
are user specific. Any base user can set an article in favourite.

Field
-----

An article is mainly composed of a title and a body. The later is an html field
that can contain text, images, link to other articles or records from other
models, templates, etc..

The other fields are used to organise the articles between them. Notably:

- field_id: This field (and the inverse field child_ids) is used to
determine the hierarchy between articles. An article can have sub-articles.
So a main subject is not a section but an article that have sub articles.
There is no limit on how many level we can have in the hierarchy.

- sequence: The sequence field is working as the following:
Each parent have its own sequence for its children. So the sequence is not
common for each articles in the database, but specific for the children of a
same parent. The resequencing is done among the children of the same parent.
If some articles has no parent, there are considered as the root articles and
all root articles have their own sequence too.

Views
-----

The main knowledge view is a tweeked form view that displays all the
articles in a side panel hierarchised tree view to allow quick access to each
articles without having to navigate back to a list or kanban view. Apart from
that side panel, this form view mainly displays only the title and the body
but also integrate custom buttons to manage the articles (creation,
deletion, move to, share, set to favourite, ...). All those functionalities
will be developed later in this message.

The tree view will be used as an advanced search to find an article that cannot
be found easily via the ctrl-K command. The later command will be implemented
in a later commit.

Side Panel
----------

Resequencing and hiearchy: From the side panel, drag and droping an article can
resequence the articles between them and/or change the parent if the moved
article.

Article Menu
------------

On the top left, we keep the usual breadcrumb that is "hybrid" between the usual
backend and the articles
=> that is very important as we want users to navigate between both smoothly

In the breadcrumb, one can click on the star to add an article to the favorites
or on its name to rename it.

On the top right, one can:
    - Click on create to create a new private article
    - Click on share to open the share modal:
        -> One can publish an article (so that non-users can access it)
        -> Copy the link to send it somewhere else
        -> Or manually send "invites" (which are simply email notifications
        with a link towards the article)

    - Click on the kebab menu button to open the "More" menu where they can:
        -> MoveTo: opens a specific model to define a new parent, ...
        (that is basically as drag and dropping it in the side panel)
        -> Lock: prevents all edition of the content until it is unlocked
        (purpose: avoid accidental edits)
        -> Duplicate: creates an exact copy with the same parent
        -> Delete: throws a classic "Are you sure" modal and if you are sure,
        you can delete it (-> all children then go up one level)
        -> Have a glance at who edited it last and when

Acces Rules and mermbership
-----------------------------------------

The access are defined by the two following fields:
internal_permission = selection (none / read / write)
article_member_ids = decorated m2m
    - article_id (mandatory)
    - partner_id (mandatory)
    - permission = selection field (none / read / write)

The category in which an article is depends on both fields.
- Workspace: internal_permission != none. Everyone can see it.
    There can also be some members on the article.
    Note: Everyone = every internal users.
    E.G.: Everyone can see it except Marc Demo. (member.permission = 'none')
          Everyone can read it but Only Marc Demo can write.
          Everyone can see it + some external partners.
- Shared: internal_permission == none + have multiple members. 
    Only the members can see it.
- Private: internal_permission == none + Only one member AND have 'write' access
    This member is the 'owner' and only them can see it.

An admin can always see and edit every article.

The current user (except for admin) has no access to articles:
- that are not shared with them:
    internal_permission = 'none' and not a member or member.permission='none'
- that are private but is not the owner:
    internal_permission = 'none' and not the owner
- that are 'public' (in workspace) but user have specifically 
member.permission = 'none'

The current user (except for admin) can edit an article only if:
- internal_permission = 'write' AND not member.permission = none
OR
- is member and member.permission='write'

Editing an article means that the user can change write on the article but also
change the access rules of the article. But, a user that can only see an article
can only share the link of the article, and consequently, add a member but in
read access only.

Constraint:
An article should always have at least one user having write access on it.
In other words, there can't be any article in the following situations:
- internal_permission = 'none' and no members
- internal_permission = 'none' and only one member that have read access
- internal_permission = 'read' and no members with write access.

Chatter Display
------------------

The chatter is a normal chatter except that:
    -> it takes more horizontal space (as in Email Markeitng)
    -> It is not displayed to non-internal users (we'll see if we do a
    portal-like layout later but I doubt it)
    -> It is never displayed above the fold, even if my article is a one-liner.
    One always needs to scroll down to make it appear

There users can:
    - Discuss among themselves (ask for help, correct a typo, suggest
    improvements, ...)
    - Schedule activities
    - Follow an article (we could have a subtype to be notified whenever a new
    child is created, for example, ...)

Search and Advanced Search
--------------------------

Searching is done through the command palet. Just as we have '#' for channels,
'/' for menus and '@' for users, we'll add '?' for articles

The command palet is accessible by either
- Hitting CTRL+K (and then adding ? to search among articles)
- Clicking on the fa-book icon of the chatter (first slides), which already
adds the '?' so that one can start searching straight away.
- Clicking on the "Search An Article" (button upper in the side panel)
while reading another article, where the '?' is automatically added too)

The search display while in the command palet shows the first X articles,
ordered by:  My Favorites , Most Favorites, The Rest
The layout is:
Icon, Article name, star if it's a favorite of mine, "— " , Parent's name in
text-muted and a bit smaller. => We add bold to what matches the search.
This bold feature has been added in standard for the occasion in an earlier
commit.

If I am not happy with the search results, I can do an "Advanced Search",
which sends me towards a normal Odoo list view where I can search, filter,
groupby, ...

If no results are found and I have enough access, I get a link that allows
to create a new (private) article with this title (ideally the name and first
line would already be set)

This feature will be added in a later commit.

Commands & Features
-------------------

One of the goals of the Knowledge app is to empower users in their daily work
by providing templates. For this effect, some editor commands will be added but
those ones will be added in later commit.

TODOS
-----

TODO: Make sure ctrl+K is respecting the order of display (first: favourite,
most favourite, then: the rest)

TODO: when creating from ctrl+K : name and first line would already be set using
the search query

TODO: fix ugly scrollbar hide for chatter to appear only on scroll down the end
of the article.

TODO: From create button (not in side panel) create an article in private,
not under the one selected.

TODO: Check deletion of intermediary article
-> its children must become children of its parent.

TODO: Maybe fixup the Add Form view with this one as a lot of code from this
commit is modified to make the main view work properly.

TODO: Review security and access rights (add base users in read access, knowledge
user group for CRUD, and admin group that can have access to everything, even
private articles of other users.)

TODO: fix resequencing when creating or duplicating articles

TO ADD in this commit
---------------------

TO ADD: breadcrumb commit from JBN

TO ADD: ctrl+K from Fabio

Task-2674460