erp5_data_notebook: ZBigArray may not be available, add it to well_known_unserializable_type_tuple if possible.

erp5_data_notebook: Don't save ZBigArray in data notebook. It may be too big that zope process may crash.

from commit message
> We have a constraint preventing closing accounting periods if there are still some accounting transactions that are in "current states" (ie. not delivered / cancelled), but this constraint should not be fooled by accounting lines in stock table that does not have an account as node, but just an acquired organisation.

We already fixed another problem where such lines where "getting in the way" in c61cde5b

But here, it's at inventory level, we want to get "all accounting movements from this section during the period"., excluding these "not really accounting" lines.

I used the same approach as the one we applied when we discovered in !215 , there was code doing:
`getInventoryList(node_category="account_type")`
as a way to get only movements on accounts, relying on the facts that accounts have an account type category.  This stopped working and we accepted it because this use case was not really valid. Instead, we did a first query getting all account and passing this as a `getInventory(node_uid=`

I don't think we want to support `node_portal_type` in Inventory API, because the concept of *portal_types* does not really belong in Inventory API to me.

To  prevent creating many portal types (Tax, Discount etc) we concluded:
 * Resources (and Movements) are classified by their *use* category
 * Deliveries are classified by their *ledger* category
 * Nodes are classified by their *role* category

So the "pure" approach is maybe to add a role category on all accounts and query inventory with `getMovementHistoryList(node_category="role/accounting_node")`.

I'd say let's merge this for now, but if you have better idea or anything to add please go ahead, I wanted to create an open place for discussion and explaining why i did all this.

/cc @tc @vpelletier @georgios.dagkakis @Nicolas

/reviewed-on nexedi/erp5!236

We have a constraint preventing closing accounting periods if there are
still some accounting transactions that are in "current states" (ie. not
delivered / cancelled), but this constraint should not be fooled by
accounting lines in stock table that does not have an account as node,
but just an acquired organisation.

So that ERP5Site_getAuthenticatedMemberPersonValue can really be replaced
by portal_membership.getAuthenticatedMember().getUserValue() (and for
consistency on other ERP5User getters).

git grep -l ERP5Site_getAuthenticatedMemberPersonValue | xargs sed -i 's!\.ERP5Site_getAuthenticatedMemberPersonValue()!.getPortalObject().portal_membership.getAuthenticatedMember().getUserValue()!g'
Plus s/portal.getPortalObject()/portal/g where modified by above regex.
Plus manual edits of the few remaining matches.
Special mention for DiscussionThreadModule_addReply, which forgot to
actually call the script.

This is not a stand-alone test.

erp5_data_notebook: If wrong setup method was added, then remove it otherwise jupyter becomes permanent unusable state.

erp5_data_notebook: Don't try to serialize well known unserializable objects and ignore any exceptions happened during serialization otherwise jupyter becomes permanent unusable state.

erp5_data_notebook: Support _repr_html_. Object such as pandas' DataFrame is rendered as HTML in Jupyter.

This reverts commit fc67555b.

zope.{interface,component} implement Interfaces through __implements__,
__implemented__ (both implementedBy instances) and __provides__ (ClassProvides
instance) attributes set on the class itself through implementedByFallback
(zope.interface.declarations).

However, this implementation creates circular references by referencing the
class itself and thus erp5.* classes (and all its Accessors instances) were
never GC even after a reset.

When running testXHTML and installing the Unit Tests bt5s:
  * After 10 resets:  21MB leak (~  7% of Zope process USS).
  * After 20 resets:  70MB leak (~ 18% of Zope process USS).
  * After 28 resets: 122MB leak (~ 26% of Zope process USS).

Fixes browsing ERP5 documents without activity tables available.
Of course, as most modifications trigger activity creation, no
modifications are possible. But this improves read-only access in
degraded conditions.
Also, by design a successful query must return one line, so do not test
returned value before processing it.

Allows recovering from broken connection strings, as ERP5 authentication
still relies on having a working catalog.