Init default point slice pools in models and expr

[colega]

Sometimes those packages could be used outside of the application lifecycle and the point slices should be initialized in order to avoid panics.

Signed-off-by: Oleg Zaytsev mail@olegzaytsev.com

[Dieterbe]

From devdocs/expr.md:

Note that the expr library can be called by different clients. At this point only Metrictank uses it, but we intend this library to be easily embeddable in other programs.
It's up to the client to instantiate the pool, and set up the default allocation to return point slices of desired point capacity.
The client can then of course use this pool to store series, which it then feeds to expr.
expr library does the rest. It manages the series/pointslices and gets new ones as a basis for the COW.
Once the data is returned to the client, and the client is done using the returned data, it should call plan.Clean(),
which returns all data back to the pool (both input data or newly generated series, whether they made it into the final output or not).

I think the above makes sense, as any caller application will need to deal with point slices before calling expr, and also deal with them after calling expr, so it needs access to the pool, and may as well own it.

See the Pool() functions right under both of your changes.

[colega]

I see the doc, but I also have seen other programs where usage of these packages just panicked because the slice pool wasn't set before using it. This can get even trickier if this package is a third party dependency.

Why can't we just avoid panics out of the box, leaving the Pool() function for callers that want to provide a custom pool?

[Dieterbe]

I see. I suppose then we can initialize with a default pool, but change the wording in the docs to encourage callers to create their own pool to increase efficiency. (e.g. to leverage the pool during the entire series lifecycle, not just within expr)

[colega]

WDYT about the wording in 20bb93c ?

[Dieterbe]

LGTM