The update of the source location of a move is not a good idea, as
shown in the test case that is modified by this commit and explained
below.
In general, a stock.move will be linked to a stock.picking whose
location_id and location_dest_id are defined by the picking type.
As such, the stock.move will inherit these locations and it is the
assignation of the stock.move that will create a stock.move.line
where the location (in case of outgoing picking) or the destination
location (in case of incoming picking through putaway) will be a
sub location of the respective location defined on the move.
So, if we want to empty a stock.location and move all its content
to another stock.location, we do not want to update the location
of the reserved moves, since it can break the reservation mechanism
of Odoo, as the assignation of a move will always look into the
children locations of the move, and it is not supposed to be updated
by any internal transfer, to what could be a children location.
Then, if internal transfers were planned from the location that is
being emptied, but are supposed to be executed after the location
has been emptied, there is probably an issue with the planning and
the sequence in which both transfers are being executed.
Since the internal transfer being updated in the test case was also
moving from a shelf location to its parent (where technically the goods
are already, since they are in a child location), we should prefer not
breaking the standard workflow of Odoo instead of supporting a corner
case with an internal transfer.
I guess we can revisit my assumption if we have a good reason to update
the stock location, but the one that was tested doesn't seem to be
good enough to justify breaking a standard mechanism.
