* remove references to basestring & unicode (use relevant pycompat
  helpers)
* remove some str calls (either entirely or replaced by relevant
  helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views

* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
  is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
  codecs (via #encode) so replace all calls to str.encode('base64'),
  also b64encode is a bytes->bytes conversion so attempt to properly
  handle that

issue #8530

Backport of P3 semantics fixes from master

So that was a fun one: mock.patch calls would regularly fail refusing
to find the addon in odoo.addon (e.g. essentially getattr(odoo.addon,
'account_budget' deep within the bowels of mock).

Turns out the answer is that our import hooks would not be used for
many imports: while in Python 2, sys.meta_path is empty and the
default finders are run after all meta_path finders fail as noted by
the documentation[0].

However when the import system was rewritten in Python 3.3[1]
meta_path was "despecialised" and the default finders were moved to
meta_path rather than be a hidden part of the import machinery[2]:

> sys.meta_path and sys.path_hooks now store all of the meta path
> finders and path entry hooks used by import. Previously the finders
> were implicit and hidden within the C code of import instead of
> being directly exposed.

The result of this change is that ``sys.meta_path.append`` means the
default finders should take priority and the custom ones should be
fallback. This is the exact opposite of what we want.

Fix issue by ``sys.meta_path.insert``-ing our finders at the start of
the path rather than appending them at the end. This should change
nothing in Python 2 but seems to fix the issue in P3.

[0]
https://docs.python.org/2/library/sys.html?highlight=meta_path#sys.meta_path
[1] https://docs.python.org/3/whatsnew/3.3.html#importlib
[2] https://docs.python.org/3/whatsnew/3.3.html#visible-changes

https://bugs.python.org/issue13936

That's a pretty sensible change, but it turns out we did have some
bits of resource which implicitly depended on the old behaviour.

In Python 2, hasattr swallows *any* exception raised during the
access. In Python 3, it only swallows AttributeError.

Accessing an attribute on an unbound threadlocal proxy raises
RuntimeError, while running test_ir_http_mimetype ``request`` is
unbound, in Python 2 ``hasattr`` would return ``False`` on an unbound
threadlocal, in Python 3 it lets ``RuntimeError`` pass through blowing
up the test.

Fix this by just checking if the threadlocal is bound by using it as a
boolean…

In Python 3 round:

* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
  None)
* discards the negative sign when rounding to 0

Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.

Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.

This is hinted at but maybe not clearly spelled out by the official
documentation:

> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.

Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.

Use case to reproduce the bug:
- Set multi location in settings
- Set warehouse's deliery method as pick/pack/ship
- Deliver a product to customer
- Process a return from customer to output.
- Create a return from output to pack ->
Unable to reserver product.

It happens because return moves where not linked together but have
the picking that created the return as origin.
Thus action_assign does not detect the return moves and can't
guess the real quantity available.

This commit add a behavior that will create links between
return move. It can be guess from parent move(the picking's move from which
the return is created) and its move dest/orig that have already
created other return. It also correct action assign because
the group by could retourn same line with return moves.
It add a test that check returns and links between them.

When deacreasing a quantity on a PO it will decrease the quantity
of an associated move. When the move's quantity reach 0, previously the
move was unlinked and aslo the picking if all moves inside were unlinked.

However the destination move(s) still exist with the quantity that has been
removed in the original move. It can confuse the end user which have a move without
origin.

This commit cancel the move/picking instead of unlink them. Thanks to this
the end user still have the link with the original moves and can guess from where
their destinations moves come from. It also remove the filter on PO in order
to display the canceled picking.

commit 0a960c08757a8ba5e1dc1dd36c17a35de8913975 introduced change about
reserved quantity that set it to 0 once the move is done.

This commit add views improvement. If the move lines are done
reserved quantity does not really matter and thus it is better
to not display it.

Modify the decorator on stock picking that change the font to red
if the quantity processed is greater than the reserved quantity.
This decorator does not trigger if the picking is in state done since
reserved quantity is always 0.

When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.

However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.

This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).

The quantity reserved for move was never modified once the move
is done. It is a nonsense to have a reserved quantity for a done
move.

This commit add a constraint that ensure the quantity of
move line to be 0 if it is in state done. Also it add a write
on move_line's 'action_done' function that set the reserved quantity
to 0 for all move line processed.

It does not introduce any change on the stock move itself since the
reserved quantity is the sum of all its move lines's reserved quantity.

Adding the step to do when the user want to delete the MO.

Improve the message for the end user.

- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
    that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
    This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
    This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.

It happens because the function still use the old fields
utilized before refactoring introduced by commit b3180c84

This commit adapt the function by using quantity instead of qty.

When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.

Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.

Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.

Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.

Fixes #18511

A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).

Commit 7cd2f637 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.

This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.

This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.

IE11 seems to be always using cache when doin an XHR request with the
same GET request.

It can be changed in several ways:

- returning a header: "Cache-Control: no-cache"
- altering the GET request with a nonce
- using the POST method instead of GET

to solve it, in this change the HTTP header is added on the response.

opw-752270
closes #18787

 'default_get' should return a value for employee
 when asked, even if it is not a timesheet.

When we try to print an invoice from POS, this is cause by changing
method signature and that we cannot choos the report template anymore.

Refactoring in rev: https://github.com/odoo/odoo/commit/e80238042c9d93d492ea8b06b0041aced0d81dcd

Since the refactoring of report in rev: https://github.com/odoo/odoo/commit/e80238042c9d93d492ea8b06b0041aced0d81dcd

Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".

This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.

Computation of the field 'Difference amount' was wrong as it was converting amounts in base currency in the following use case:
- company currency USD
- invoice currency EUR
- payment's journal currency USD but payment's currency EUR
- invoice of 100€, payment of 20€: difference was not 80€ because it was converting to USD

[FIX] account: show payments in multi currencies with the rate of the invoice date instead of the payment date (so that we can see a meaningful residual)

Without this patch, the residual of the invoice doesn't correspond to the real residual of the invoice's receivable/payable line(s)

The function registration_new must return a type json.

opw:765643

The display name of a location should be recomputed when the name of the
parent location is changed.

opw-761463

*account_asset

When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.

Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).

This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
  icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
  case before this rev.

Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.

Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"

Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.

Backport of 0de067ca
(and 9b8bc5e5)

Rev. c5bd5092 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.

Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.