Decide the fate of VarInfo.num_produce

[mhauru]

This is a feature of VarInfo that's only used by particle samplers. Having it stored in VarInfo doesn't feel like the right place, and we would like to get rid of it when we refactor VarInfo/SimpleVarInfo. However, having the sampler keep track of it is apparently not easy either, and might require changes to how some contexts work around samplers. We could also drop it, but that would mean losing existing particle sampler functionality.

Discussed with @torfjelde, @sunxd3, and @willtebbutt.

[torfjelde]

@yebai should also probably have a look at this 👍

[yebai]

We could move this to AdvancedPS, e.g. adding a num_produce field to AdvancedPS.LibtaskModel:

https://github.com/TuringLang/AdvancedPS.jl/blob/6c2cee380ce53ab25483e57aaaf381fbb8f31fd3/src/model.jl#L49-L53

Each LibtaskModel realisation corresponds to a particle / VarInfo.

cc @FredericWantiez @willtebbutt

[yebai]

@mhauru, do you want to try this? I'm happy to help you through the process if you have any questions.

[yebai]

For reference, the only place that we use the num_produce field is below:

DynamicPPL.jl/src/varinfo.jl

Lines 1716 to 1719 in 24a7380

	for i in 1:length(vi.orders)
	if i in gidcs && vi.orders[i] > get_num_produce(vi)
	vi.metadata.flags["del"][i] = true
	end

which is called by a function in Turing,

https://github.com/TuringLang/Turing.jl/blob/78d110afc17daaedbc492695d258c5eb8541463e/src/essential/container.jl#L41-L44

Particle MCMC samplers use this to remove obsolete random variables in VarInfo after a particle is copied/forked (as part of the resampling step in particle filtering algorithms).

[mhauru]

Can do. Will take me a moment though, I'll have to start by reading some wikipedia to get a basic idea of what particle MCMC does.