Fixed value for Max Priority field in Deposit TX delays chain propagation

[LyonSsS]

Context: SDK GMP call uses a fixed value for the Max Priority field, when the TX is constructed. This is fine other chains, except for Polygon where behavior on chain is to increase this value also. With this context, the Deposit TXs, sent by the SDK will be delayed by the miners, and propagation will take more than usual.

Implementation details

We need to customize the Deposit TX in a way to dynamically populate the Max Priority fee, based on oracle fee.

Testing details

Re test on various chains that have a dynamic use of Max Priority fee and validate it fits the general median value reported on chain.

Acceptance Criteria

As a new User I am using the SDK example EVM to EVM for GMP Message AND I am filling in all the correct data of RPC source for Polygon AND I am filling in all the correct data for destination contract and RPC for Base WHEN I am trigging the SDK example THEN I am expecting to see my Deposit TX on chain with a Max Priority value similar to median value of the chain.

NOTE: A relayer TX example on polygon with Max Priority : 29.799513299 Gwei https://polygonscan.com/tx/0x232f4722b4730db323a0e4a9192c21c053a8d63b496c87b216e89dfcacec84ae A Deposit TX on polygon with 1.5 Gwei for Max Priority https://polygonscan.com/tx/0x84c2e335337380116ae2abe8767e06b3936807683159029be1be4ac8703873c9