floodgate: split spam_with_account function in 3

What

This merge request refactors the Floodgate transaction spamming logic by splitting a large, monolithic function into three smaller, well-scoped functions.

Why

The previous implementation concentrated multiple responsibilities—retry logic, per-transaction callbacks, nonce sequencing, and salvo coordination—into a single, complex function. This made the code difficult to read, reason about, and evolve safely. Splitting the logic improves maintainability, clarifies control flow, and reduces the cognitive load for future changes or debugging.

How

The refactoring introduces three distinct functions with clear responsibilities:

• retry_transfer: encapsulates the retry policy and callback handling for a single transaction, including event emission and confirmation handling.
• salvo: manages the sequential submission of a fixed number of transactions (a salvo), handling nonce progression and waiting for confirmation of the last transaction.
• spam_with_account: is simplified to orchestrate repeated salvos, delegating detailed logic to the functions above.

This preserves the existing behavior while making the flow of retries, confirmations, and nonce management explicit and easier to follow. No functional changes are intended.

Manually testing the MR

• Run Floodgate with the same configuration as before and observe that transaction throughput and retry behavior are unchanged.
• Verify via logs/events that retries, confirmations, and dropped/refused transactions are still reported correctly.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR