Split DataContainer to a HDF and non HDF part

[pmrv]

Basically DataContainer is renamed to DataContainerBase and the methods used for HasHDF/HDFStub are moved to a new sub class DataContainer. Docstrings are replicated where necessary. No API changes for users.

In preparation of https://github.com/orgs/pyiron/projects/7/views/1

@liamhuber Pulling DataContainer out should be just a matter of copy/paste now.

[liamhuber]

@liamhuber Pulling DataContainer out should be just a matter of copy/paste now.

I think this may be of even more imminent utility to @samwaseda?

Will review shortly, but I peeked at the diff and it was what I intuitively expected so that should go pretty smoothly.

[liamhuber]

99% as expected and no nits or anything.

The only thing I'm not sure of is the consistent use of type(self) for a bunch of recursion checks. Most of these seem to me like they should instead hard-code the class they're written in, so that if derived classes hold an instance of their parent class the recursion can continue uninterrupted. I'm not totally sure that's the right behaviour choice though.

At any rate, now that we explicitly have a base and child class, I think it's important to extend the tests to cover the case of child-holds-parent-instance to encode whatever behaviour decision you make.

[niklassiemer]

LGTM once @liamhuber s concerns are matched

[pmrv]

 Traceback (most recent call last):
  File "/home/runner/work/pyiron_base/pyiron_base/tests/flex/test_pythonfunctioncontainer.py", line 63, in test_with_executor_wait
    self.assertTrue(job.server.future.done())
AssertionError: False is not true

@jan-janssen Sounds related to your recent developments. Would that be fixed by #1300 or #1301?

[jan-janssen]

@jan-janssen Sounds related to your recent developments. Would that be fixed by #1300 or #1301?

The issue was solved by restarting the CI. We have to take a look at this and maybe increase the time out in case the issue continues to come up.

[jan-janssen]

Once this is merged, we should also release a new pyiron_base version.

[pmrv]

@jan-janssen Sounds related to your recent developments. Would that be fixed by #1300 or #1301?

The issue was solved by restarting the CI. We have to take a look at this and maybe increase the time out in case the issue continues to come up.

I think it makes more sense to just use the timeout directly in the tests, then this can never happen.

[jan-janssen]

@pmrv As more tests were requested, I changed the status of this pull request to draft until the tests are added.

[liamhuber]

Nice, type checking and testing changes lgtm.