Robust Transaction Submission Feedback Cycle

The way the application currently submits transactions to the platform can result in undesirable behavior when the system is under very high load.

This is the current transaction submission workflow:
- the application creates a transaction
- the transaction is passed to the platform, which puts the transaction into a queue
- at a later time (potentially much later in a system under high load), the transaction is removed from the queue and placed into an event

In scenarios where transactions submitted quicker than can be handled, transactions end up sitting in a queue for a very long time before being put into an event. Sometimes, this may be so long that the transaction is no longer viable when it reaches consensus (e.g. Hedera enforces a time limit for which each transaction is valid).

Holding a transaction for a long time, and then submitting it only for the transaction to be not handled due to timeouts, is not optimal behavior. We waste network resources doing work that provides no benefit, and end users see many transactions time out.

When under high load, it would be much better if the application instead rejected a certain fraction of incoming transactions immediately, instead of letting them time out. I propose the following changes:

- instead of holding transactions waiting to be submitted in a platform queue, the application holds waiting transactions in a queue that it controls
- create API that allows for the platform to ask the application for the next available transaction
- the platform will only ask for an available transaction if the transaction is about to be put into the next event
- the application should not give the platform transactions that have expired or are very close to expiring (by the application's own reckoning)
- if the application observes transactions expiring before the platform takes them and puts them into events, it should incrementally throttle the rate at which it is willing to accept user transactions

```

public interface TransactionPool {
/**
* Get the next transaction to be added to an event.
*
* @return the next transaction, or null if there are currently no available transactions
*/
@Nullable
byte[] getNextTransaction();

/**
* Check if there are any available transactions at this moment. Note that this method returning true does not
* necessarily mean that {@link #getNextTransaction()} must return an actual transaction, since the application is
* free to arbitrarily decide at any time that a transaction should not be submitted.
*
* @return if there are any available transactions at this moment
*/
boolean hasTransactions();
}

////////////////////

public interface SwirldMain {

// ...

@NonNull getTransactionPool();
}

```