Closes: #43

Closes: #86

This commit adds two metrics:
* gettor_request_total the total number of requests done to gettor, with
  the command, platform and locale of the original request.
* gettor_link_response_total the total number of responses with links
  sent with platform and locale that was used.

Closes: #51

HTTP endpoint where the dynamic bridges can be sent. It has support for
multiple dynamic bridges providers, with different authentication tokens
for each of them.

Closes: #98

To avoid sharing *requestHashKeys* between different goroutines let's
use a worker to write to metrics so a single goroutine has access to it.
This solves a crash on the telegram distributor.

Closes: #108

When bridge authority restarts it might produce bridge descriptors
without the running flag, as it hasn't tested the bridges yet. Let's
ignore those updates.

Closes: #102

Use bridgestrap results to distribute only tested and functional
resources. Unless the ratio of functional resources is too low, so rdsys
keeps distributing resources after restarts (having most resources
untested) or in case of bridgestrap failures.

Closes: #96

Is a function only used by the backend and not useful for distributors.

Old telegram accounts have smaller IDs and new ones have bigger IDs. The
logic was inversed here.

The prometheus metrics can't be initalized multiple times. To make the
tests work they are now a global variable.

After the transition from bridgedb to rdsys many 'telegram' bridges (old
bridges) are comming from 'moat' or other distributors that could be blocked in
certain locations. For old telegram accounts let's distribute bridges from both
pools the dynamic 'new' bridges and the bridge authority 'old' bridges.

Closes: #101

Closes: #107

Closes: bridgedb#40043

Oid is used to detect if a resource has changed, they don't get updated
unless the oid has changed. Let's include any information that can
change, like the distributio request, flags or oraddresses in the oid.

Before that change rdsys was missing some bridge changes and not
updating bridges until rdsys was restarted.

Closes: #104

There is no need to return few bridges for builtin birdges, and the
current implementation had the chance to return twice the same bridge.

Closes: #100

Uses telegram to distribute resources.

Closes: #77

The only consumer (for now) of Hashring.GetMany is the moat distributor,
the distributors doesn't have the test status of the resources. Let's
get bridges independently of their test status.

AFAIK current rdsys implementation doesn't use the bridgestrap test
status to decide wich bridges to distribute. I just created an issue to
investigate that (#96).

The new version of go vet considers that an error.

In a certain rotation period distribute the same bridges for the same IP
range.

Closes: #79

It is used by moat distributor now.

Closes: #87

/moat/circuvemtnion/defaults API provides some settings as fallback for
the situations where we don't have a working configuration for the
country.

Closes: #40045

Closes: #59

The distribution request was lost when bridge transports were used.

Closes: #93

Closes: #90

Refactor the status handler and the AddOrUpdate so they only use the
exposed methods of the hashring.

Transport bridges include the IP address in the hash index, together
with the fingerprint and the type. We can not address them directly just
knowing the fingerprint.

For now let's do a sequential search over the fingerprint, in the future
this might become a problem and we might need to make it more efficient.

Closes: #88

Not all the users of the Hashkey need to know how is it hashed and what
is the polynomial being used.

For it let's derivate resources.BridgeBase from core.ResourceBase so we
have access to the BlockedIn function.