Typically, the server has three kinds of data:

1) Static data, that typically come from loaded files on disk.
2) Modified data -- starting with static data, modify it for game purposes (think "blowing a hole in a wall" or "looting a chest.")
3) Ephemeral data -- data that is created out of "thin air" -- think player avatars, fired projectiles, and the like.

The server typically knows about all the data, and when a player joins, can send the player the list of:
- what static data to load (this might be as simple as the name of a level file with a version/checksum)
- what deltas to apply to that loaded level data
- what ephemeral entities have been added, with type and property values

Games that require you to be joined at the start of the level, only need 1) and 3), which is probably the main reason many games have that requirement :-)

The server will generally decide to do this at some particular time step. Any change that happens after this time step needs to also be sent to the client, so it can "wind forward" to "current state."
In fact, most network synchronization can be thought of as clients continually "winding forward" to apply changes and "catch up" with world state, once the initial load/sync has happened.

What I am trying to figure out now is, how to share the current game state with newly connected user. Eg. The server spawns a new entity for the player on certain map, but at First the player has no information about the level. That means, even when he receives the first state update packet from the server, he can' update entities (locations...) because they don't exist yet in his local state yet.

What is usualy the aproach to this, do you have certain kind of message for that, telling the client to spawn entities that exist in the level?

Yes, you can do that. Send message to spawn object, with given type, and construction data.

There are ways to make this more efficient. As you can tell, that will be a lot of data. You can call this game-sync, where the entire game state is transmitted.

In a more complex game structure, the server only sends a 'view' of the game. What the client can actually see (think Minecraft). Then further updates are changes to that view. And also, despawning entities no longer in view, and spawning entities coming into view.

Also for the level map, when he enters a different one, should I send him new map ID to load, or maybe use rpc?

I'm not sure what you mean. If you take the 'view' approach, the mechanics are kinda automatic. The user leaves an area. Therefore it's no longer in view. Therefore send a 'destroy area' command.

The user loaded a new area. Therefore send a bunch of 'spawn entities' command, the stuff the user can see when entering the area'.

Think of the host as kind of versioning system. Takes the current client view, takes the current game state, and generates a bunch of commands necessary for the client to sync-up his view with latest game state.

'Spawn entity' (create new entity here).
'Despawn entity' (destroy that entity no longer in view).
'Update entity' (send entity state diffs between the last state acknowledge by the client, and the latest game state).

And, that's pretty much it. The host needs to know what the client sees, what the client has confirmed to have received, so the host can work out to send what's new to the client.

So, for each client known to a host, keep track of each of their view of the game, and every frame, update that view with the current game state.

Client just arrived in an area? Well then, send him everything he can see from that area, since he knows nothing of it.

Note that this will be a large amount of information. Then what you can do is send that reliably (can call this full-state), and wait for the client acknowledgement receipt, before sending him any further updates (can call it delta-updates).

Furthermore, you can schedule updates at different rate, for example depending how far entities are from the client position. But that's more of a nicety than a requirement, and there are some caveats.