Don't reset REG_FIFO_ADDR_PTR

[torntrousers]

As per the discussion in #268 and #218

[morganrallen]

After digging into the datasheet I cannot find a compelling reason resetting REG_FIFO_ADDR_PTR should be done.

[mchacher]

I do confirm.
could be good as well to create a task that is calling the callback function instead of having this call in the ISR which is not safe at all.
Sharing below the code I have used on my side. Hope this can help.

volatile int _dioRiseInterruptCounter = 0;
portMUX_TYPE mutexDioRise = portMUX_INITIALIZER_UNLOCKED;

/**

• onDio0Rise
• Handle Dio0 interrupt
  */
  void IRAM_ATTR LoRaClass::onDio0Rise()
  {
  portENTER_CRITICAL(&mutexDioRise);
  _dioRiseInterruptCounter++;
  portEXIT_CRITICAL(&mutexDioRise);
  //LoRa.handleDio0Rise();
  }

/**

• Manage RX / LoRa data received. To be executed in a separate task

*/
void LoRaClass::taskRxLoop(void *pvParameters)
{
// configure dio0 interrupt
vTaskDelay(1);
pinMode(LoRa._dio0, INPUT);
LoRa.writeRegister(REG_DIO_MAPPING_1, 0x00);
attachInterrupt(digitalPinToInterrupt(LoRa._dio0), LoRaClass::onDio0Rise, RISING);
while (true)
{
if (_dioRiseInterruptCounter > 0)
{
portENTER_CRITICAL(&mutexDioRise);
_dioRiseInterruptCounter--;
portEXIT_CRITICAL(&mutexDioRise);
LoRa.handleDio0Rise();
}
// give the opportunity to the IDLE task to run, and so avoid the TaskWatchDog timer to trigger a reset
vTaskDelay(10);
}
}

[morganrallen]

This isn't related to this pull request.