Not only for performance, but also because they would break documents
on which asComposedDocument is used.

This implements dependency resolution to sort amount generator lines
so that a base_amount is never contributed after it was applied.

Before, it was required to sort manually using int_index or float_index, which
can be difficult for a human when there are many lines spreaded over different
containers (which are merged by composition). Another problematic case is when
a set of lines is configured by a user (like discounts & fees) and must all be
applied before other lines (taxes) that are installed elsewhere by the
developer: how to reliably make sure the latter have index values that are
already greater than those entered by the user ?

Setting int_index or float_index is now only useful for lines:
- with same reference: only the maching one with lowest index is taken
  into account (commit 68ec6bda)
- applying to intermediate values of some base_amount
  (commit 10be013b)

The difficult part to solve dependencies is that the calculation for a
given base_amount may trigger the application of other base_amount, and so on
recursively. In order to support this case, amount generator lines are first
applied on a dummy amount, and getGeneratedAmountQuantity must be call
unconditionally for all dependent base_amount. So optimizing like

  return 3 <= delivery_amount.getGeneratedAmountQuantity('base_amount/1') \
      or 1 <= delivery_amount.getGeneratedAmountQuantity('base_amount/2')

is wrong except if 'base_amount/2' is only contributed by the movement or if
you sort manually with indices.

Dependency resolution has precedence over indices. But since the sort is stable,
lines will remain sorted by index if it respects dependencies.

Preliminary commit only to indent a big section of code.

Before we dropped amounts with quantity=0 and we stopped doing that because
it broke expand. However, there's still one case when such amount can be
ignored, i.e. when there's no base_application set on the amount generator.

When a user explicitely enters 0 on a Trade Model Line, total price must be 0
no matter what is set on the resource.

Default getPriceCalculationOperandDict script calls getPricingVariable
type-based script directly if variable_additional_price is not 0.

Redirect to absolute url of respective Web Section so if 'Renderer ID' is set (as usually when a web section is used for forum) the UI displays iforum UI which is not the case when default 'view' of Web Section is used if we redirect to using form_id.
As thread is show immediately correct message to not confuse users.

If an object has no uid yet and has no acquisition context to the portal,
getUid() fails.

Default is derived from id(aq_base(ob)) which is even more efficient.

The method on XMLObject was also redundant because it inherited the same one
from Base.

also readAsciiFile normilises CRLF/CR/LF.

https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.blockalgo-module.html#MODE_CFB

Accelerates (at least) Person's jump_to_accounting action.

Also, factorise related key string generation.

Also, use xrange as it's faster than range even for short sequences.

Also, get rid of single-use locals and unneeded list copy.

These related keys override auto-generated ones without adding any value.
Also, they are not declared as related keys, so declaration is
auto-generated and may not match ZSQLMethod parameters, causing errors.

Although it should never happen in normal use, it may happen during an
upgrade when property sheets fail creating accessors (ex: broken object
because portal type moved to a different Business Template).

Also, avoid reindexing when object is not modified.

This also fixes the problem that in recent pytz common_timezones is a LazyList that does not work in restricted python

make FTPConnector.getFile binary mode by default, because ascii mode only works with utf-8 encoding.

also propagate binary mode to SFTPClient.file().