BEFORE THIS CHANGE
==================

When website_appointment was installed, and when the appointment
type was configured with date_first=False, is_auto_assign=False,
then the appointment main route rendered a different page content
in order for the booker to select first the user / resource, each
having a large card with picture (or placeholder) and name (as well
as function and website_description for users).

It had a dedicated chevron in the progressbar and was referred
to as the operator selection step. There was an option to 'skip
user / resource selection' and see the full availability.

AFTER THIS CHANGE
=================

In order to ease the user experience, we now inline the user and
resource selection on the date & time selection step. It takes the
form of a grid of smaller cards, that can be selected when the same
conditions are met. They are rendered above the calendar. Their
content is the same. The user can click on the card and the calendar
will update accordingly. They can change and see updated availability
directly, which was not possible before, as the page was different.

In order to reproduce the 'skip user/resource selection' feature, a
dedicated card 'No preference' is used and put at the end of the grid of
cards. This will in turn compute full availability using all available
resources / users.

As before, when coming back from an error or using the chevrons
hyperlinks, the selection is remembered and the default selection
(user / resource / no preference) is kept and the availability computed
accordingly when landing on the page (unless having skipped selection).

The whole behavior is now available directly in appointment (no need
for website) and replaces the dropdown used previously. Corner cases
(no availabilty screens, manage capacity or not) are handled as well.

A test is modified to reflect these changes.

USER DEFAULT / SELECTED SIMPLIFICATION
======================================

A simplification of a rather hard-to-maintained flow ramification
was done as well, as the meaning of 'selected' has evolved.

Before, for manual selection starting with user / resource, having
staff_user_id or resource_selected_id set meant selection was done and
only that user / resource was to be considered. Now, this is not the
case anymore, as one can change the user / resource on the date and
time selection page.

This means we only use that 'selected' value for an initial selection:
if the user / resource has availability, then we use it. Otherwise, we
use the first available one (see `_get_slots_values`). Therefore we move
mostly the logic on x_default and `get_slots_values`.

The resource_selected_id and staff_user_id are now used when coming back
from an error or using the chevrons to navigate between steps.

AUTO ASSIGN SIMPLIFICATION
==========================

While simplifying, the x_default and x_selected were simply removed
from the controller logic when is_auto_assign is True. There was a
case of having a single staff user that lead to seeing its information
on the side bar. This has been removed as this was not consistent, nor
with resource behavior, nor with the 'auto assign' philosophy.

We now never show the user / resource in date and time, details
steps. We also do not propagate resource_selected_id to the
registration page.

TO SUMMARIZE
============

There are three flows depending on the appointment configuration:
(e.g. here for resources)

1. auto assign: no use of resource_selected_id. no display of the
selected resource / user even if there is only one, in the right
column.

2. time then resource: no use of resource_selected_id since we
need to compute for each slot all available resources.

3. resource then time: resource_selected_id, set for instance using
a chevron, is used to initialize the selection. If not available,
we still initialize to the first available resource. The value is
propagated in the url.

LINKS
=====

UPG PR: https://github.com/odoo/upgrade/pull/8724

Task-5187767

On odoo.com, we noticed that Knowledge can be slow when there are a lot of articles: For 4365 articles, it takes between 1.5 and 2.3 seconds to load the list view listing all the articles the user has access to. This PR will try to optimize the performance and the scalability of the Knowledge module by reworking the methods used to compute the permissions of a user on an article and the methods used to search the articles the user has access to or the articles the user can edit.

Those methods are computationally expensive and are used extensively in Knowledge. They are the main hot spots of the module: The search method is for instance used in the `domain_force` of the ACL rules for some group of users (see: `user_has_access` and `user_has_write_access`). They are hence used each time the user opens an article. It is therefore important to optimize those functions to make Knowledge blazing fast and responsive.

# Benchmark

To assess the performance of the new query and indexes, we wrote custom scripts that will perform a server call with the same configuration as the main list view and form view of Knowledge. This should ensure that we optimize the response time of the views we frequently use.

For 10k articles, we got the following results:

## List view

Before:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   58.21ms |   8.53 |
|  Demo | 1139.65ms | 179.37 |

After:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   85.95ms |   7.48 |
|  Demo |  174.17ms |   4.98 |


## Form view

Before:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   56.66ms |   8.03 |
|  Demo |  469.51ms |  15.48 |

After:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   35.81ms |   4.74 |
|  Demo |   64.45ms |  17.41 |


task-3771333