Describe the project you are working on

Multiplayer game using the low-level ENectConnection API.

Describe the problem or limitation you are having in your project

I'd like to process all available ENetConnection events within a frame/tick. From the discussions in godotengine/godot#51466 and lsalzman/enet#126 (comment) we can see that the correct approach is something like the following:

enet_host_service(host, 0, 0);
ENetEvent event;
while (enet_host_check_events(host, &event) > 0) {
    switch (event.type) {
         // ...
    }
}

What's important is that there is one call to enet_host_service per tick and enet_host_check_events is used to process any remaining events after the first one processed by enet_host_service.

ENetConnection::check_events has this functionality (it's used by the high-level multiplayer API), but it's not exposed to GDScript.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Expose ENetConnection::check_events to GDScript so when using ENetConnection directly, developers can process more than one event per tick without unexpectedly queueing more events than intended.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The approach mirrors how ENetConnection:service is exposed to GDScript, exposing the method using the same return API but without any arguments.

// enet_connection.cpp

Array ENetConnection::_check_events() {
	Event event;
	Ref<ENetPacketPeer> peer;
	EventType type;
	check_events(type, event);
	Array out = { type, event.peer, event.data, event.channel_id };
	if (event.packet && event.peer.is_valid()) {
		event.peer->_queue_packet(event.packet);
	}
	return out;
}

void ENetConnection::_bind_methods() {
	// ...
	ClassDB::bind_method(D_METHOD("check_events"), &ENetConnection::_check_events);
	// ...
}

If this enhancement will not be used often, can it be worked around with a few lines of script?

It cannot be worked around without introducing incorrect code. Repeated calls to ENetConnection::service within one tick can lead to different amounts of time spent accepting events per tick.

Is there a reason why this should be core and not an add-on in the asset library?

It's modifying code in the enet module.