Should the recommendation limit be considered static or vary at runtime?

[dzeber]

Along the current line on the dev branch of formulating graph transformations as Treatments, we can think of "building the recommendation graph" as just another treatment.

Once the treated graph is built, we could then apply a Recommend treatment which removes the lower-weighted edges for each add-on, and stores a _recommendation_graph in the recommender instance. The recommend() function would then just look up from the precomputed graph, rather than sorting at runtime as it does now.

This makes most sense if the number of recommendations (limit) is considered a static property of the service. If we intend for clients to be able to request different numbers of recommendations at runtime, recommend() should compute the recommendation list dynamically, as it does now (excluding the tie-breaking computation as per #48).

[dzeber]

As per discussion on Sep 10, the recommendation limit should be considered static for the foreseeable future.