The purpose of retracker is to be tracker and an announce proxy at the same time.

retracker shall expose it's internal tracker cache as standalone tracker,
implementing HTTP and UDP announces. Available for non-proxied peers, serving as regular tracker.

Then, server another HTTP and UDP endpoints as announce proxy. Local peer requesting announce
to proxied tracker shall be matched by announce URL and tracker key (if there is), or another identifier
like peer_id. Proxy endpoint is available only for requests that match forementioned tracker key.
When request is made to proxy endpoint and it matches key - re-announce to destination trackers should be made and
on successful peer list retrieval - local tracker cache updated. If not, peers from cache should be returned.

On re-announce to destination trackers, proxied peer's real IP must be injected into announce request and
other parameters should remain same as in original request.

Whether retracker exposes its cache as tracker or not, the local tracker data shall be present all time.
When there is need to expose local tracker a tracker endpoint should be declare in config. Tracker endpoint
is HTTP or UDP server responsing to BitTorrent announces just like if it was any other regular torrent tracker.


Announce request coming from local peer contains local (peer) data: ID, uploaded, downloaded, and so on.
Announce response contains peer set.

Proposal 2 to retracker scheme:
	Local peers will announce to tracker of retracker. Retracker job will find peer that are eligible for re-announce,
	and announce them to destination trackers, with all local data like downloaded/uploaded, BUT IPs rewritten
	with rules, that will be specified in config to translate proxied peer's IP.
	Apart from re-announces, tracker will act like regulat BitTorrent tracker: serving peer lists and keeping track
	of torrents.

Maven exec with args:
	mvn exec:java -Dexec.args=''