Goal
---
When a "Schedule interview" mail template is sent from an application,
if the recipient uses the link the schedule a meeting, the meeting
should be linked on the smart button on the application form.

Note
---
Previously we had a demo "Schedule Intreview" mail template, from which
a recipient could schedule an interview -- but the `appointment.invite`
was the same for all recipients and the meeting would not be linked back
to the application.

Changes
---
* Edit appointment booking route to take an applicant_code in the url
* The applicant_code makes it possible to match calendar event with
  applicants at creation time
  (not just an applicant_id to avoid "attackers" guessing ids)
* the mail template now creates an invite link for the recruiter's
  `anytime` appointment type and the current applicant.
* Remove applicant_id from appointment invites
  * instead we append the applicant_code to the url when copying the link
    to share
  * all other buttons in this view also append the applicant_code
  * Note: this is needed because the field relation made it impossible to
    use the same invite for several applicants

Beneficial "Side Effects"
---
* This makes it so we don't have to regenerate an invite for every
  applicant when sending a link for a specific appointment type
* Fix the following bug:
  * when admin has no `anytime` appointment type -- go to the
    calendar view from the applicant form button.
  * *Share Calendar* -- the invite's applicant is the current one
  * repeat for another applicant -- no new invite is generated and the
    applicant stays the same.

task-4251911

Issue -->

When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.

Solution -->

Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.

Benchmarks -->

For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view. 

| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s | 

opw-4606704