Gratuitous ARP request – same destination and source IP addresses, uses of GARP

You're almost 100% correct. Slight corrections bolded below:

1. HostE will send an ARP Request with a target address of Router2's IP address. The destination MAC address of the ARP packet will be ffff.ffff.ffff, which would indeed make it a broadcast. Router2 responds unicst with its MAC address, and HostE generates the packet with a Source and Destination IP of 192.168.3.1 and 192.168.1.1, and a Source and Destination MAC of 7777.7777.7777 and 8888.8888.8888 (respectively).
2. Router 2 will receive the packet, and consult its Route Table to determine the Next Hop for the 192.168.1.0/24. If Router2 doesn't already know Router1's MAC address, it will issue a broadcast ARP Request for it. Once it learns it, it will then forward the packet leaving the Source/Destination IP unchanged, and encapsulating the IP packet with a Layer 2 header with a Source and Destination MAC of 5555.5555.5555 and 3333.3333.3333.
3. Router1 receives the packet and consults its Route Table to determine the destination Network is directly connected. Router1 sends a Broadcast ARP Request for the IP 192.168.1.1 to learn HostA's MAC address, and then finally forward the packet to the final destination.

And to answer your last question. Whether HostE gets its address from DHCP or not, the process flow would appear as above if HostE did not have an entry in its ARP Cache for Router2's MAC address.

IF, Router2 was the DHCP Server (which it doesn't have to be). And Router2 just assigned HostE its address. Then theoretically, HostE would know Router2's MAC address. But ARP entries don't last forward, particularly on clients. For example, my Windows 7 laptop keeps ARP entries for only 34.5 seconds (see below).

So even if Router2 was the DHCP server, and gave HostE its IP address, sooner or later HostE's ARP cache would time out, and it would have to run the broadcast ARP request all over again, just like if HostE had always only had a static IP assigned.

C:\Users\eddie>netsh interface ipv4 show interfaces 20

Interface Local Area Connection Parameters
----------------------------------------------
IfLuid                             : ethernet_11
IfIndex                            : 20
State                              : connected
Metric                             : 20
Link MTU                           : 1500 bytes
Reachable Time                     : 34500 ms     <-----
Base Reachable Time                : 30000 ms
Retransmission Interval            : 1000 ms
DAD Transmits                      : 3
Site Prefix Length                 : 64
Site Id                            : 1
Forwarding                         : disabled
Advertising                        : disabled
Neighbor Discovery                 : enabled
Neighbor Unreachability Detection  : enabled
Router Discovery                   : dhcp
Managed Address Configuration      : enabled
Other Stateful Configuration       : enabled
Weak Host Sends                    : disabled
Weak Host Receives                 : disabled
Use Automatic Metric               : enabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 1800 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 0
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled

When in doubt, the RFC which creates the protocol usually has the answer. RFC 826, An Ethernet Address Resolution Protocol has a description of what happens when a host receives an ARP request, including the rationale for why it is done the way it is. It says that you, "Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields." Some may interpret this to mean that you only change the sender fields, while other may think that swap means swap. This is how you get conflicting information and implementation of these protocols. Often a succeeding RFC will come out to explain which direction is the correct one. In this case, ARP is really a layer-2 communication, so the destination IP address isn't really the issue in a reply because the reply is back to the requesting layer MAC address, and it is not passed back up the stack to layer-3.

By the way, it doesn't matter if both devices are in the same subnet since a PC should never ARP for an IP address not in its subnet; it will send an ARP for the configured gateway IP address, instead of a destination IP address not in its subnet.

Packet Reception:

When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet.

?Do I have the hardware type in ar$hrd? Yes: (almost definitely)  
[optionally check the hardware length ar$hln]   ?Do I speak the
protocol in ar$pro?   Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the <protocol type, sender protocol address> pair, then the new hardware address supersedes the old one. Related Issues gives some motivation for this.

Generalization: The ar$hrd and ar$hln fields allow this protocol and packet format to be used for non-10Mbit Ethernets. For the 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other hardware networks, the ar$pro field may no longer correspond to the Ethernet type field, but it should be associated with the protocol whose address resolution is being sought.

Why is it done this way??

Periodic broadcasting is definitely not desired. Imagine 100 workstations on a single Ethernet, each broadcasting address resolution information once per 10 minutes (as one possible set of parameters). This is one packet every 6 seconds. This is almost reasonable, but what use is it? The workstations aren't generally going to be talking to each other (and therefore have 100 useless entries in a table); they will be mainly talking to a mainframe, file server or bridge, but only to a small number of other workstations (for interactive conversations, for example). The protocol described in this paper distributes information as it is needed, and only once (probably) per boot of a machine.

This format does not allow for more than one resolution to be done in the same packet. This is for simplicity. If things were multiplexed the packet format would be considerably harder to digest, and much of the information could be gratuitous. Think of a bridge that talks four protocols telling a workstation all four protocol addresses, three of which the workstation will probably never use.

This format allows the packet buffer to be reused if a reply is generated; a reply has the same length as a request, and several of the fields are the same.

The value of the hardware field (ar$hrd) is taken from a list for this purpose. Currently the only defined value is for the 10Mbit Ethernet (ares_hrd$Ethernet = 1). There has been talk of using this protocol for Packet Radio Networks as well, and this will require another value as will other future hardware mediums that wish to use this protocol.

For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is taken from the set ether_type$. This is a natural reuse of the assigned protocol types. Combining this with the opcode (ar$op) would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor/debugger more complex (see Network Monitoring and Debugging below). It is hoped that we will never see 32768 protocols, but Murphy made some laws which don't allow us to make this assumption.

In theory, the length fields (ar$hln and ar$pln) are redundant, since the length of a protocol address should be determined by the hardware type (found in ar$hrd) and the protocol type (found in ar$pro). It is included for optional consistency checking, and for network monitoring and debugging (see below).

The opcode is to determine if this is a request (which may cause a reply) or a reply to a previous request. 16 bits for this is overkill, but a flag (field) is needed.

The sender hardware address and sender protocol address are absolutely necessary. It is these fields that get put in a translation table.

The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table).

The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet.

There are no padding bytes between addresses. The packet data should be viewed as a byte stream in which only 3 byte pairs are defined to be words (ar$hrd, ar$pro and ar$op) which are sent most significant byte first (Ethernet/PDP-10 byte style).