Bug 7019

This suggested revision to the method of handling message size limits is still driven by spamc. Its objectives are:
* allow installations using the same configuration as 3.4.x to show the same
  expected behaviour.
* to provide a centralised method method of registering a non-standard maximum
  message size and making it available to all interested parties, i.e spamc,
  spamd, sa-learn and spamassassin
* to minimise and impact on spamc/spamd throughput 

The revision is presented here by describing how it works:

When spamc is asked to send a message to spamd for processing its first action is to send a message to spamd and getting a reply. This exchange uses the same session that will transfer the message to spamd for processing.
The possibilities are:

- If spamc sends zero size (no --max-size option), spamd returns the max-size
  value from local.cf if one was defined by a max-size parameter, and 512k if
  undefined, This preserves the current default behaviour.

- If spamc sends a nonzero size (from a --max-size CL option), spamd returns
  the smaller of that or the 256MB hard limit.

After this exchange the size limit is compared with the message, which is sent to spamd provided that its size does not exceed the returned value and processing proceeds as at present.

This approach does what I'd like and can also support KAM's variable limits scheme without requiring changes on his part by allowing his client side to have complete control of the processed message size via the spamc --max-size option. His scheme looks like a good one for handling traffic peaks on a high volume, heavily loaded mail system while not interfering with spam detection unless it is absolutely necessary.

sa-learn, spamassassin and any other message handling programs that get added to the SA package should all honour the configured max-size value set in local.cf along with its 512KB default value because this eliminates surprises that can arise when hand running tests on anomalous messages. For the same reason all SA programs should honour the 256MB hard limit and should probably implement a --max-size option as well.