Add ScalableSingleBinary operational run mode

[zalegrala]

What this PR does:
Add a new module ScalableSingleBinary that will run all services and also make use of memberlist for cluster awareness.

Which issue(s) this PR fixes:
Fixes #86

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[zalegrala]

What other documentation do we want to include here? We don't currently say much about the target=all, so I'm wondering how much needs to be said to differentiate.

[zalegrala]

I've included some brief docs about our run modes.

[joe-elliott]

So far nice work. Have a few cleanup requests on the doc and then let's add a docker-compose example that uses this new mode so people can see a simple way to set it up.

[zalegrala]

Oh whoops, with all the rebasing I failed to add the docker-compose example. I'll get that updated and clean up the docs per your suggestions. Thanks for the review.

[mdisibio]

Late to the conversation, but I would like to propose another module naming change. With the addition of a scaleable single binary mode, I'm finding the naming of the "all" module somewhat misleading. It runs all components but differently. The new scaleable mode is really closer to "all", as in it runs all components without changes.

Could we do something like the following? Note it doesn't change the commandline for --target=all

// The various modules that make up tempo.
const (
	SingleBinary         string = "all"
	ScalableSingleBinary string = "scalable-single-binary"
)

[zalegrala]

I've included the change you mention @mdisibio.

[zalegrala]

Hold for @KMiller-Grafana review.

[zalegrala]

The docs have been updated from @KMiller-Grafana, and I also dropped the configuration section for this mode. Hows that look now?

[zalegrala]

Thanks for the review and updates @KMiller-Grafana.

[KMiller-Grafana]

Suggested change

	to deploy but cannot but can not horizontally scale. Refer to
	to deploy, but cannot but can not horizontally scale out by increasing the quantity of components. Refer to

[KMiller-Grafana]

This rewrite misses telling readers what scalable single binary mode is. Please consider this suggestion.

Suggested change

	A scalable single binary deployment is similar to the single binary mode in
	that all components are deployed in one binary but it is capable of
	horizontally scaling. This mode offers some flexibility of scaling without the
	A scalable single binary deployment is similar to the single binary mode in
	that all components are deployed within one binary. Horizontally scale out is achieved by instantiating more than one single binary. This mode offers some flexibility of scaling without the configuration

[KMiller-Grafana]

Suggested change

	is per component which allows for greater flexibility in scaling and more
	is per component, which allows for greater flexibility in scaling and more

[KMiller-Grafana]

Suggested change

	This example aims to make it easier to measure and analyze tempo performance in
	micro-services mode. There are already many examples for running tempo under
	load, but they use the single-binary approach and are not representative of
	what is occurring in larger installations. Here tempo is run with separate
	This example aims to make it easier to measure and analyze Tempo performance in
	micro-services mode. There are already many examples for running Tempo under
	load, but they use the single-binary approach and are not representative of
	what is occurring in larger installations. Here Tempo is run with separate

[KMiller-Grafana]

Suggested change

	This example is expected to be used in conjunction with tempo development in a
	rapid feedback loop. It is assumed you have a working go installation and a
	copy of tempo already cloned somewhere.
	This example is expected to be used in conjunction with Tempo development in a
	rapid feedback loop. It is assumed you have a working Go installation and a
	copy of the Tempo repository already cloned somewhere.

[KMiller-Grafana]

Suggested change

	As tempo is designed to be very horizontally scalable, the key metrics are _per volume unit_, i.e. spans / s / cpu core.
	As Tempo is designed to be horizontally scalable, the key metrics are _per volume unit_, i.e. spans / s / cpu core.