Investigate possible memory leaks

[LSViana]

In #18, there has been a mention of possible memory leaks in the operations executed through YDotNet.

This issue intends to:

1. Investigate the possible issues
2. Document the discoveries
3. Create a procedure and, possibly, an automated way to detect such issues in the future

Investigated scenarios (this list is not final):

• [x] Doc
  • [x] Create instances without options
  • [x] Create instances with options
  • [x] Read Id
  • [x] Read Guid
  • [x] Read CollectionId
  • [x] Read ShouldLoad
  • [x] Read AutoLoad
  • [x] Invoke Clone() and Dispose()
  • [x] Observe clear (leaking)
  • [x] Observe updates V1 (leaking)
  • [x] Observe updates V2 (leaking)
  • [x] Observe after transaction (leaking)
  • [x] Observe subdocs (leaking)
• [x] Text
  • [x] Create instances
  • [x] Insert text
  • [x] Insert embed
  • [x] Remove text
  • [x] Format text
  • [x] Read the chunks
  • [x] Read the string representation
  • [x] Read the length
  • [x] Observe changes (leaking)
• [x] Array
  • [x] Create instances
  • [x] Insert range
  • [x] Remove range
  • [x] Get by index
  • [x] Move by index
  • [x] Iterate (leaking)
  • [x] Read the length
  • [x] Observe changes (leaking)
• [ ] Map
  • [x] Create instances
  • [x] Insert
  • [x] Read by key
  • [ ] Remove by key
  • [ ] Remove all
  • [ ] Iterate
  • [ ] Read length
  • [ ] Observe changes (leaking)
• [ ] XmlText
  • [ ] Create instances
  • [ ] Insert text by index
  • [ ] Remove text by index
  • [ ] Format text by index
  • [ ] Insert embed by index
  • [ ] Insert attribute
  • [ ] Read attribute
  • [ ] Remove attribute
  • [ ] Iterate
  • [ ] Read as string
  • [ ] Read the previous sibling
  • [ ] Read the next sibling
  • [ ] Read the length
  • [ ] Observe changes (leaking)
• [ ] XmlElement
  • [ ] Create instances
  • [ ] Read tag
  • [ ] Read as string
  • [ ] Insert attribute
  • [ ] Read attribute
  • [ ] Remove attribute
  • [ ] Iterate
  • [ ] Read child length
  • [ ] Insert text by index
  • [ ] Insert element by index
  • [ ] Remove items by index
  • [ ] Read item by index
  • [ ] Read the previous sibling
  • [ ] Read the next sibling
  • [ ] Read parent element
  • [ ] Read first child
  • [ ] Walk the tree
  • [ ] Observe changes (leaking)
• [ ] Branch
  • [x] Read a sticky index
  • [ ] Observe deep (leaking)
  • [ ] Create read transaction
  • [ ] Create write transaction

---

Other fixes:

• [ ] Change subscriptions to be stored in their parent collections to prevent Delegate disposal

[LSViana]

First round of investigations:

1. Creating documents without explicitly disposing them leaves the memory disposal for the GC, which can cause a very high memory usage until the operating system memory is close to exhaustion (this behavior was seen in both Windows and macOS) but it's still freed as expected
2. Creating documents and explicitly disposing them has constant memory usage

For instance, this screenshot demonstrates the scenario (2):

Further investigations will be conducted for other operations.

[LSViana]

Second round of investigations:

1. It was discovered that creating Doc instances with DocOptions that included string properties would cause an increasing usage of memory until the Dispose() method of DocOptionsNative was called
2. This was improved to call that Dispose() method manually and now the memory usage to create Doc instances with DocOptions is constant too

[LSViana]

Third round of investigations:

1. To prevent relying on clients of the library to invoke Dispose() on resources, I'm implementing destructors on public classes exposed by the library.
2. The private or internal classes or structs shouldn't implement Dispose() since it's expected that the library, internally, calls Dispose() correctly wherever it's needed.

[SebastianStehle]

I think input will also leak memory. e.g. when creating a new collection input a new block of memory is allocated and just the pointer is given to y-crdt. But the pointer is never released. I think a finalizer is needed here.

[SebastianStehle]

@LSViana Can we close this?

[LSViana]

@SebastianStehle No, the initial work I did here was useful for detecting and fixing memory leaks.

Given the previous discoveries, I believe it's important to check for possible leaks in the pending items too. It's not a complex task, it's more laborious and repetitive, I'll try to do a little bit every day.