Remove {bpmodels} dependency before CRAN submission

[joshwlambert]

No description provided.

[joshwlambert]

Thinking about ways to solve this issue. A few that seems reasonable:

1. Take internal simulation code from {bpmodels} and place it in {superspreding}. The simulation functionality will not need any new features and as {bpmodels} is retired then there will not be getting new features added anyway. It is licensed under MIT so there will not be any licensing issues and I can add the function author as an author in {superspreading}.
2. Rework the .sim_network_bp() code from {simulist} to be a simple branching process model.

Other less favourable options:

3. Remove functionality that requires branching process simulation from {superspreading}.
4. Write branching process simulation from scratch.

@jamesmbaazam, @Bisaloo & @chartgerink what do you think is best?

Another possible solution I didn't list is to take on {epichains} as a dependency to simulate the branching process. In my opinion this doesn't really solve the issue at hand as {epichains} is not on CRAN yet. It is a viable long-term option, to keep in mind.

[chartgerink]

As to the best of my understanding of the situation: If the code from option 1 isn't a lot (for example, hundreds of lines), this seems preferable. Once epichains is on CRAN removing would not be too much work so there's also a pathway for ensuring this code is not long lasting and forwards compatible.

[jamesmbaazam]

Thanks for tagging @joshwlambert. I agree with @chartgerink.

I think the option with the least trouble is (1). The bpmodels code could potentially live in superspreading forever if the {epichains} reparameterizations could cause breaking changes in superspreading. For example, there are plans to reparametrise the infectious period in {epichains}. But I think we could re-assess the engine used here when {epichains} goes on CRAN.

[sbfnk]

I agree on option (1).

[joshwlambert]

Closed as PR #103 is merged.