enable leaderboards with user-generated cache and token

[fcaps]

related to #445 and #454

How this works:

1. If a user now opens the "leaderboard, he must be authenticated
2. if there is no cache, the server will create a in-memory cache using the token from the user (we replace it once we got a m2m client)
3. if there is already some user creating the cache, the request waits 2 seconds before it times out
4. if there is already a cache, it will be served if not stale (5min ttl)
5. every 10min the garbage-collection will remove stale cache-entries

Downsides:

• someone is now the cache-looser, and has to wait 3-7 sec if he is the first one
• memory consumption, but i got less than 3mb for data from xyz
• restarting the server will purge the cache (we need redis or similar to change this)
• the leaderboard frontend is not really responsive if the cache needs to be created (the is no loader, no error-message if something fails etc. but this was so even before my change)

Upsides:

• no setInterval
• no more container startup issues bc. of the leaderboard
• flexibility via the LeaderboardService -> change to m2m client, or even use it in a cronjob etc.

Other improvements:

1. simplified leaderboard object, it was split into 2 array lists (all this player[0] and player[1] stuff)
2. user-suggestion can now be clicked and will filter the list (why was the suggestion even there if you cannot click it...)
3. removed duplicated leaderboard.js -> this was loaded twice in the browser and almost took my sanity

[Brutus5000]

I can't really test whether this works without deploying it. Code looks mostly clean, so we can give it a try after rebase.

[fcaps]

I can't really test whether this works without deploying it. Code looks mostly clean, so we can give it a try after rebase.

it work perfectly with xyz. services (hydra + api), you only need to set this in the .env