/reviewed-on nexedi/slapos!82

The problem is explaned here: https://bugs.chromium.org/p/chromium/issues/detail?id=260239

The use of header Vary: Origin dosen't fix the problem on chrome so I disabled the cache
with Pragma "no-cache". This doesn't cause issue because most of monitor files are
modified every minutes and sync happen at least every 5 minutes. So the better solution
is to disable cached.

fixing segmentation fault on css opacity rendering

/reviewed-on nexedi/slapos!81

  Update documentation to follow up recently changes. 
  Link to json schemas instead duplicate the information.

forgot to update md5sum ...

From Cédric message

When a client do a request, you pass the Accept-Encoding header. For me it is:
```
Accept-Encoding:gzip, deflate, sdch, br
```

But in a lot of case the cache configuration has `Vary:Accept-Encoding` . `Accept-Encoding` request header may vary a lot from a client to another but one of the common denominator is `gzip`. So in order to avoid a multiplication of cache versions in CDN, if `gzip` is present in the `Accept-Encoding` request header all other format are stripped from the request in order to reduce variation in Trafficserver.

When this parameter is activated:
```
Accept-Encoding:gzip, deflate, sdch, br
```
is transmitted as
```
Accept-Encoding:gzip
```
And
```
Accept-Encoding:deflate, sdch, br
```
is transmitted as
```
Accept-Encoding:deflate, sdch, br
```

Quoting Romain:
> As you can see at https://lab.nexedi.com/nexedi/erp5/blob/master/bt5/erp5_web/ToolTemplateItem/caching_policy_manager.xml
> , caching policy manager often set Cookie in the Vary  header.
> For the CDN, it means that each query on the same URL but with a
> different cookie will never be a HIT, and so, query will always access
> ERP5 backend.

Some people might be confused and think it is paths

"I remember it is something scary ;)"

  The software release was re-written to use jinja2 templates