Hi and welcome!
The first thing to mention would be that you should be considering splitting games into smaller chunks. Your game is almost entire within the main function and all code is in one file. Separating it into the parts it needs can make it easier to maintain and also focus on a specific area. For an example, your entity class could be separated into its file(s).
Don't be too disheartened by this comment. My first game was the same.
Another big thing to note is that it's generally thought of as bad to use almost any form of global variables. Remember that you can create objects/variables inside main and then pass them to functions that need them.
This is even more serious with SFML resources; it should not be done. Again, you can create them inside main and pass them around (by reference or pointer). Another option is to use global pointers and then create them within main using those global pointers. This can be a little less safe however.
It seems that you are using a fixed timestep. The fact that it repeats multiple times per frame to "spend" the elapsed time in equal chunks is, I would say, the right approach.
It seems, however, that some things have been caught up in that part. For example, for each frame (once through the window-is-open loop code), you only need to do the event loop once and the window's clear, draw, display once. You have included the event loop inside the timestep update and, although this sounds like it might run more often so isn't a problem, it will actually not test for events until an entire timestep has passed so could cause a small amount of "lag".
I don't know if you are drawing over every pixel in the window but for an Asteroid game, I suspect not, so you should be including the window's clear() just before drawing to the window.
I noticed that you have a state system in place, which can be a very confusing area to implement. You have taken the simple method of "iffing" dependant on a variable and this method does work fine. However, you may want to look into more advanced methods for implementing states as your games get more complicated and have more and more states.
Also, again, this state checking in inside the timeframe thing but I mentioned this above. You probably don't need fixed timestep in your menu, for example.
I was looking through Asteroids' main.cpp as I wrote this so it may not also apply to "space shooter".