tests: Increase the dead interval to be longer for neighbor testing

tests: Increase the dead interval to be longer for neighbor testing

the ospf_basic_functionality/test_ospf_lan.py script is setting
up a lan env that will have 4 ospf routers on it and shutting/no
shutting interfaces with various priorities to see that ospf
is properly choosing roles.  I am consistently seeing the
ospf_basic_functionality/test_ospf_lan.py script failing
where it is saying a neighbor is not in the correct state.

Upon examination of the logs we are seeing this:

2023/04/24 09:16:42 OSPF: [M7Q4P-46WDR] vty[7]@(config)# interface r0-s1-eth0  <----- This is where we no shut the interface
2023/04/24 09:16:47 OSPF: [M7Q4P-46WDR] vty[7]@> enable
2023/04/24 09:16:47 OSPF: [M7Q4P-46WDR] vty[7]@# show ip ospf neighbor all json
2023/04/24 09:16:53 OSPF: [QH9AB-Y4XMZ][EC 100663314] STARVATION: task ospf_ism_event (556af08a5b4c) ran for 6038ms (cpu time 0ms)
2023/04/24 09:16:53 OSPF: [HKQ2F-8D0MY][EC 100663315] Thread Starvation: {(thread *)0x556af19da020 arg=0x556af19c0dd0 timer  r=-5.086     ospf_ase_calculate_timer() &ospf->t_ase_calc from ospfd/ospf_ase.c:635} was scheduled to pop greater than 4s ago
2023/04/24 09:16:53 OSPF: [M7Q4P-46WDR] vty[18]@> enable
2023/04/24 09:16:53 OSPF: [M7Q4P-46WDR] vty[18]@# show ip ospf neighbor all
2023/04/24 09:16:55 OSPF: [M7Q4P-46WDR] vty[7]@> enable
2023/04/24 09:16:55 OSPF: [M7Q4P-46WDR] vty[7]@# show ip ospf neighbor all json
2023/04/24 09:16:55 OSPF: [M7Q4P-46WDR] vty[7]@> enable

This test is setting the dead interval to 4 seconds, seeing a 6 second delay where the os has gone to town
(probably because of the high load on the system ) and not choosing the correct neighbor as the DR.

OSPF when coming up and after seeing the first neighbor, goes into a waiting period before
the DR is elected.  If the neighbor does send it's hello packets but they are not processed
before the wait timer pops because of the starvation event, then the wrong neighbor
will be elected DR.  Let's give this test a bit more time to decide who the
DR is in case everything goes a bit south.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>