this stack implementation has a fixed-size. new items are pushed to the
front and, if the capacity has been met, the last item gets evicted. if
you push an item onto the stack that was already on the stack, this
"bumps" that item by merely moves the item to the front (as opposed to
allowing duplicates). the capacity is set at initialization.
the intended use case for this data structure is for the iroh-tracker to
only keep a fixed amount of topics and, per topic, a fixed amount of
peers. topics that are actively recalled get pushed to the front, and
peers within a topic that are seen often also get pushed to the front.
see examples/stack-example.go for how it can be used
eventually i'll refactor this to use just bytes instead as that is more
useful for the purpose of the tracker. this could also be an opportunity
to look into generics since string & byte are basically interchangeable.
TODO:
* decide on future response structure but maybe prefixing with the name is ok
* decide on error/nil values
* server: actually do things with the data sent to us by client
cblgh