This is getting to be my “hobby horse”, but interrupts are a nasty distraction to “newbie” programmers. Interrupts can be - and should almost always be - completely ignored and left to the ambit of certain library routines such as those for keeping time.
They are basically never needed for a “HID” interface and in particular should never be used for pushbuttons where there is a need to de-bounce. Interrupts are for things that need a fast response, meaning computer-fast, that is, microseconds.
In this case (as so often happens), you have been confused by the idea that an interrupt will “interrupt” the task that you are presently doing. In fact and to the contrary, it is a critical point of design that your main program as such should never know that an interrupt has occurred at all because the interrupt has left the operating state of the main routine absolutely unchanged. Interrupts are intended only for events that occur in “computer time”; that need to be attended to within microseconds. By the same token, they have to be dealt with and completed within fractions of a millisecond - if only because other such important events may require attention.
I have not used the Ethernet modules, so cannot offer particularly specific advice regarding that, but in general, you load data into the module, and it sends it. You need to do this consistently to ensure the integrity of the data, but this can be interspersed with performing other tasks and the data has to be consistent; no point stopping halfway through - if you need to send an alternate version, well, you do that after sending the first. It may be worthwhile to investigate discussions here regarding “state machines” in this regard.
Now, note in regard to your receiver description:
Note: These modules are indiscriminate and will receive a fair amount of noise. Both the transmitter and receiver work at common frequencies and don’t have IDs. Therefore, a method of filtering this noise and pairing transmitter and receiver will be necessary. The example code below shows such an example for basic operation. Please refer to the example code and links below for ways to accomplish a robust wireless data link.
It is indeed necessary to have the receiver software continuously running in order to pick up transmissions (and even then, you expect that it will miss a proportion of transmissions, so they must be repeated). The code supplied does this, and (using libraries) handles the necessary interrupts (which are regular timer interrupts) for you.
This code needs to be interleaved in a “non-blocking” manner with the Ethernet sending code so that each performs a necessary step at a time but never waiting for any event, instead passing on to the rest of the “loop” code. When sufficient data is received to form a message, that is then transferred as a block (string) from the part of the “loop” code that assembles it piecemeal, to the code that forwards it on piecemeal.