Upcoming changes for multi-tenancy

[arschles]

The internal architecture of this project will change at the next release, which will likely be v0.2.0.

Currently, when a new HTTPScaledObject is created, the operator creates a new fleet of interceptors and a new scaler for the referenced app. This behavior implies that there is a fleet of scalers & interceptors assigned to each HTTPScaledObject. There are N HTTPScaledObjects per namespace, so there are N of these fleets per namespace.

In #206, we will be refactoring the operator, interceptor, and scaler such that there is one fleet of interceptors, one scaler, and one operator per namespace. The design is detailed in this document and the work is ongoing (but almost complete) in #206.

When that PR is merged, we plan to create a new v0.2.0 release with no further very few additional changes (edited because we will likely add #168 as well) in that release, since this is a large changeset.

We have some architectural changes to make such as #225, which we plan to include in follow-up PATCH or MINOR releases (i.e. v0.2.1 or v0.3.0).

We've tried to ensure that the user experience is nearly unchanged from the v0.1.0 release, but there are some things that were unavoidable, including the fact that interceptors and a scaler will always be running and not assigned to a single application.

Please use this discussion to post questions or comments on this change.